Re: garbage collector

From

Valentin Nechayev (2:5020/400)

To

Andrey Sapozhnikov

Date

2005-06-02T11:03:24Z

Area

RU.PERL

From: Valentin Nechayev <netch@segfault.kiev.ua>


>>> 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 намеренно, упрощая реализацию, введён подсчёт ссылок вместо
того чтобы применить "самый глобальный" подход. Это _не мешает_
возможности упаковать данные: она всё равно остаётся, за счёт
просмотра всей памяти по описанному выше методу. Проблемой тут
можно посчитать разве что тот факт, что сжатие памяти требует
такого просмотра, который уже тождественен полной сборке мусора, а
значит, счётчик ссылок в этих условиях не нужен с точки зрения
академически настроенных консерваторов и ограниченно полезен с
точки зрения практиков, потому что такие сложные структуры которые
не покрываются подсчётом ссылок очень редко встречаются в
программах на перле.

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


-netch-
--- ifmail v.2.15dev5.3
 * Origin: Dark side of coredump (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 639 642 715 744 758 794 830 921 958 968 982
SEEN-BY: 5020/1057 1100 1169 1212 1234 1523 1604 1626 1642 1653 1665 1826 1829
SEEN-BY: 5020/1922 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 6035/9 6070/5 6083/11

PATH: 5020/400 4441 52 5054/1 37