Re: garbage collector

From

Andrey Sapozhnikov (2:5020/400)

To

Valentin Nechayev

Date

2005-06-06T19:40:36Z

Area

RU.PERL

From: Andrey Sapozhnikov <sapa@icb.chel.su>

Valentin Nechayev wrote:
>>>>Andrey Sapozhnikov wrote: 
> 
> 
>> AS>> сегмента данных. Теоретически ее можно подвинуть и в сторону
>> AS>> уменьшения, но только если освобожденый кусок находится в самом
>> AS>> конце,
>>
>>>Андрей, это в Си данные переместить невозможно, поскольку указатели могут
>>>храниться чёрт знает где, в языках же со сбором мусора точно известно, где
>>>находятся указатели, и процесс сбора мусора не только освобождает уже
>>>неиспользуемую память, но и собирает занятые блоки вместе - иначе память будет
>>>всё больше и больше фрагментироваться
> 
> AS> А интерпретатор Перл и есть программа написаная на C. И отнюдь не все
> AS> переменные внутри есть SV, многие структуры не отображаемые напрямую
> AS> в пространство переменных Перл выделены по Newz, многие выделены из
> AS> подключенных библиотек просто с помощью malloc.
> 
> Их можно привести к общему подходу или включить в список известных
> исключений (который существует в любом сборщике мусора).
> 
> AS> Да и SV (и его
> AS> наследники - AV, HV, GV,...) не хранят список ссылок на себя, а лишь
> AS> счетчик. Ссылка появляется - она увеличивает счетчик в переменной на
> AS> которую ссылается, ссылка дохнет - уменьшается счетчик. Как счетчик
> AS> доходит до нуля - объект становится кандидатом на зачистку.
> 
> Андрей, Ваше упоминание про "список ссылок на себя" показывает,
> что Вы вряд ли знакомы с технологией сборки мусора:)

Ух. Приложил. Не знаю даже как адекватнее отреагировать...

> Ни в Java, ни
> в Lua, ни в Lisp, ни в Scheme, ни в Python такие "обратные ссылки"
> не ведутся, и вообще они _принципиально_ бесполезны. Сборка мусора
> всегда ведётся начиная просмотром от семейства "гарантированно
> нужных" объектов, в которые входят как минимум глобальные объекты
> и объекты на стеке текущих нитей. Все прочие методы лишь
> ограниченно полезны, а глобально скорее вредны - на любую
> технологию вроде подсчёта ссылок, учёта обратных ссылок или
> просмотра типичных циклов найдётся структура, которая не
> "соберётся" подобной технологией. И только просмотр связей от
> начального семейства гарантированно нужных объектов даст надёжный
> результат. Далее методы сборки мусора уже делятся по
> консервативности, постепенности сбора или сбора за один приём,
> многонитевости и так далее, но основной принцип - как уже описано.
> 
> В Perl намеренно, упрощая реализацию, введён подсчёт ссылок вместо
> того чтобы применить "самый глобальный" подход. Это _не мешает_
> возможности упаковать данные: она всё равно остаётся, за счёт
> просмотра всей памяти по описанному выше методу. Проблемой тут
> можно посчитать разве что тот факт, что сжатие памяти требует
> такого просмотра, который уже тождественен полной сборке мусора, а
> значит, счётчик ссылок в этих условиях не нужен с точки зрения
> академически настроенных консерваторов и ограниченно полезен с
> точки зрения практиков, потому что такие сложные структуры которые
> не покрываются подсчётом ссылок очень редко встречаются в
> программах на перле.

Так вот, если опустить опусы про Lua и про то, где обратные
ссылки не ведутся - давайте поговорим о том, где они ведутся.
А ведутся они (внимание сюда, сейчас из шляпы появится кролик!) -
в Перле. Есть такая структура данных в языке Перл которая
называется weak reference, изнутри она видна как SV с
флажками SVf_ROK и SVprv_WEAKREF. Так вот она хранит список
всех, кто ссылается на объект. Но поскольку я не знаком,
с технологией сбоки мусора, то будем считать, что данной
структуры не бывает. И Перла тоже, наверное...

> Суммируя, чтобы такое работало кто-то должен написать полный
> сборщик мусора. В этом нет ничего невозможного, есть лишь текущая
> ненужность для типичных применений :)

А вот теперь поговорим о том, что же делать с внешними библиотеками.
Перл вовсю использует libc, не говоря уже разновсяческих
libssl, libzlib, libMagick, libjpeg и тысяче других. И все они
знать не знают ни о Перле и о замечательных технологиях сборки
мусора которые можно внедрить. И вот, эти глупые несчастные
библиотеки просят память у глупой libc через глупый вызов malloc,
и libc по глупости своей им кусочек памяти отдает. В конце. Потому
как в начале все занято нашим умным сборщиком мусора. И с тех пор
мы не вправе сдвинуть границу сегмента данных назад, потому
как глупые объекты глупых библиотек не догадываются о том, что
мы умеем перемещать всех и вся...

> 
> -netch-

-- 
Andrey
--- ifmail v.2.15dev5.3
 * Origin: Demos online service (2:5020/400)
SEEN-BY: 50/203 520 400/462 450/159 186 208 451/30 452/25 100 454/9 455/15
SEEN-BY: 461/33 43 74 106 132 640 464/34 465/204 467/24 469/125 200 999 478/44
SEEN-BY: 478/65 550/5068 4600/126 4614/9 4616/3 4623/56 4625/8 9 4626/100
SEEN-BY: 4627/10 4632/10 4635/4 99 1024 4641/444 4642/27 48 4657/50 5000/76
SEEN-BY: 5001/50 5001 5002/76 5002 5003/34 5006/1 5007/1 5010/53 70 146
SEEN-BY: 5011/13 5012/8 5015/4 28 214 5020/52 115 118 128 133 150 154 175 194
SEEN-BY: 5020/400 486 545 549 600 642 715 744 758 794 830 921 958 968 982 1057
SEEN-BY: 5020/1100 1169 1212 1234 1523 1604 1626 1642 1653 1665 1826 1829 1922
SEEN-BY: 5020/1930 2013 2020 2044 2142 2200 2238 2345 2590 2908 4400 4441
SEEN-BY: 5021/2 3 5022/128 5023/11 5024/1 73 5025/19 750 5026/14 49 5030/49 69
SEEN-BY: 5030/195 382 436 556 611 920 966 1016 1039 1063 1339 1520 1688 1900
SEEN-BY: 5031/7 47 63 70 5032/11 20 5033/21 35 5034/8 5035/3 38 63 5036/1 13
SEEN-BY: 5037/21 36 5038/4 5040/33 47 5041/4 5042/13 5045/7 42 5047/47 5049/1
SEEN-BY: 5049/6 157 5050/9 41 5051/15 35 5053/16 38 5054/1 8 9 35 36 37 45 50
SEEN-BY: 5054/66 67 81 85 5055/177 5056/16 5057/1 5058/77 5059/2 9 20 5060/88
SEEN-BY: 5060/90 5061/15 120 5062/1 4 7 5063/51 5064/7 35 39 5066/18 5070/26
SEEN-BY: 5070/66 1222 5071/22 5075/5 37 5077/70 80 5079/49 5080/80 1003 5081/2
SEEN-BY: 5082/6 5083/13 21 5090/23 105 108 113 5093/4 27 33 5096/18 5100/113
SEEN-BY: 6001/3 6023/1 6033/2727 6070/5

PATH: 5020/400 4441 52 5054/1 37