|
ru.perl
- RU.PERL ----------------------------------------------------------------------
From : Andrey Sapozhnikov 2:5020/400 06 Jun 2005 19:40:36
To : Valentin Nechayev
Subject : Re: garbage collector
--------------------------------------------------------------------------------
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> доходит до нуля - объект становится кандидатом на зачистку.
>
> Андрей, Ваше упоминание про "список ссылок на себя" показывает,
> что Вы вряд ли знакомы с технологией сборки мусора:)
Ух. Приложил. Hе знаю даже как адекватнее отреагировать...
> Hи в Java, ни
> в Lua, ни в Lisp, ни в Scheme, ни в Python такие "обратные ссылки"
> не ведутся, и вообще они _принципиально_ бесполезны. Сборка мусора
> всегда ведётся начиная просмотром от семейства "гарантированно
> нужных" объектов, в которые входят как минимум глобальные объекты
> и объекты на стеке текущих нитей. Все прочие методы лишь
> ограниченно полезны, а глобально скорее вредны - на любую
> технологию вроде подсчёта ссылок, учёта обратных ссылок или
> просмотра типичных циклов найдётся структура, которая не
> "соберётся" подобной технологией. И только просмотр связей от
> начального семейства гарантированно нужных объектов даст надёжный
> результат. Далее методы сборки мусора уже делятся по
> консервативности, постепенности сбора или сбора за один приём,
> многонитевости и так далее, но основной принцип - как уже описано.
>
> В Perl намеренно, упрощая реализацию, введён подсчёт ссылок вместо
> того чтобы применить "самый глобальный" подход. Это _не мешает_
> возможности упаковать данные: она всё равно остаётся, за счёт
> просмотра всей памяти по описанному выше методу. Проблемой тут
> можно посчитать разве что тот факт, что сжатие памяти требует
> такого просмотра, который уже тождественен полной сборке мусора, а
> значит, счётчик ссылок в этих условиях не нужен с точки зрения
> академически настроенных консерваторов и ограниченно полезен с
> точки зрения практиков, потому что такие сложные структуры которые
> не покрываются подсчётом ссылок очень редко встречаются в
> программах на перле.
Так вот, если опустить опусы про Lua и про то, где обратные
ссылки не ведутся - давайте поговорим о том, где они ведутся.
А ведутся они (внимание сюда, сейчас из шляпы появится кролик!) -
в Перле. Есть такая структура данных в языке Перл которая
называется weak reference, изнутри она видна как SV с
флажками SVf_ROK и SVprv_WEAKREF. Так вот она хранит список
всех, кто ссылается на объект. Hо поскольку я не знаком,
с технологией сбоки мусора, то будем считать, что данной
структуры не бывает. И Перла тоже, наверное...
> Суммируя, чтобы такое работало кто-то должен написать полный
> сборщик мусора. В этом нет ничего невозможного, есть лишь текущая
> ненужность для типичных применений :)
А вот теперь поговорим о том, что же делать с внешними библиотеками.
Перл вовсю использует libc, не говоря уже разновсяческих
libssl, libzlib, libMagick, libjpeg и тысяче других. И все они
знать не знают ни о Перле и о замечательных технологиях сборки
мусора которые можно внедрить. И вот, эти глупые несчастные
библиотеки просят память у глупой libc через глупый вызов malloc,
и libc по глупости своей им кусочек памяти отдает. В конце. Потому
как в начале все занято нашим умным сборщиком мусора. И с тех пор
мы не вправе сдвинуть границу сегмента данных назад, потому
как глупые объекты глупых библиотек не догадываются о том, что
мы умеем перемещать всех и вся...
>
> -netch-
--
Andrey
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
