Re: garbage collector

From

Valentin Nechayev (2:5020/400)

To

Andrey Sapozhnikov

Date

2005-06-06T22:39:44Z

Area

RU.PERL

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


>>> Andrey Sapozhnikov wrote: 

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

Намеренно не используя другие источники... Вы в предыдущем письме писали:

=== cut ===
 AS> Да и SV (и его
 AS> наследники - AV, HV, GV,...) не хранят список ссылок на себя, а лишь
 AS> счетчик. Ссылка появляется - она увеличивает счетчик в переменной на
 AS> которую ссылается, ссылка дохнет - уменьшается счетчик. Как счетчик
 AS> доходит до нуля - объект становится кандидатом на зачистку.
=== end cut ===

Из этого чётко и однозначно следует, что для типичного применения никаких
обратных ссылок не ведётся. То, что в случае weak reference что-то ведётся -
случай значительно более частный.

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

И что с того? Сборкой мусора можно собрать перловые объекты, которых в
типичной программе значительно больше, чем занятого другими библиотеками.
И ничто не мешает кроме стандартного malloc (или даже своей замены
стандартного malloc) использовать собственную арену, на которой и производить
выделение памяти для своих данных. Слава богу, платформы без mmap() или
её полного аналога сейчас вымерли.


-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 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