|
ru.perl
- RU.PERL ----------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 02 Jun 2005 11:03:24
To : Andrey Sapozhnikov
Subject : Re: garbage collector
--------------------------------------------------------------------------------
>>> Andrey Sapozhnikov wrote:
> AS>> сегмента данных. Теоретически ее можно подвинуть и в сторону
> AS>> уменьшения, но только если освобожденый кусок находится в самом
> AS>> конце,
>> Андрей, это в Си данные переместить невозможно, поскольку указатели могут
>> храниться чёрт знает где, в языках же со сбором мусора точно известно, где
>> находятся указатели, и процесс сбора мусора не только освобождает уже
>> неиспользуемую память, но и собирает занятые блоки вместе - иначе память
>> будет всё больше и больше фрагментироваться
AS> А интерпретатор Перл и есть программа написаная на C. И отнюдь не все
AS> переменные внутри есть SV, многие структуры не отображаемые напрямую
AS> в пространство переменных Перл выделены по Newz, многие выделены из
AS> подключенных библиотек просто с помощью malloc.
Их можно привести к общему подходу или включить в список известных
исключений (который существует в любом сборщике мусора).
AS> Да и SV (и его
AS> наследники - AV, HV, GV,...) не хранят список ссылок на себя, а лишь
AS> счетчик. Ссылка появляется - она увеличивает счетчик в переменной на
AS> которую ссылается, ссылка дохнет - уменьшается счетчик. Как счетчик
AS> доходит до нуля - объект становится кандидатом на зачистку.
Андрей, Ваше упоминание про "список ссылок на себя" показывает,
что Вы вряд ли знакомы с технологией сборки мусора:) Hи в Java, ни
в Lua, ни в Lisp, ни в Scheme, ни в Python такие "обратные ссылки"
не ведутся, и вообще они _принципиально_ бесполезны. Сборка мусора
всегда ведётся начиная просмотром от семейства "гарантированно
нужных" объектов, в которые входят как минимум глобальные объекты
и объекты на стеке текущих нитей. Все прочие методы лишь
ограниченно полезны, а глобально скорее вредны - на любую
технологию вроде подсчёта ссылок, учёта обратных ссылок или
просмотра типичных циклов найдётся структура, которая не
"соберётся" подобной технологией. И только просмотр связей от
начального семейства гарантированно нужных объектов даст надёжный
результат. Далее методы сборки мусора уже делятся по
консервативности, постепенности сбора или сбора за один приём,
многонитевости и так далее, но основной принцип - как уже описано.
В Perl намеренно, упрощая реализацию, введён подсчёт ссылок вместо
того чтобы применить "самый глобальный" подход. Это _не мешает_
возможности упаковать данные: она всё равно остаётся, за счёт
просмотра всей памяти по описанному выше методу. Проблемой тут
можно посчитать разве что тот факт, что сжатие памяти требует
такого просмотра, который уже тождественен полной сборке мусора, а
значит, счётчик ссылок в этих условиях не нужен с точки зрения
академически настроенных консерваторов и ограниченно полезен с
точки зрения практиков, потому что такие сложные структуры которые
не покрываются подсчётом ссылок очень редко встречаются в
программах на перле.
Суммируя, чтобы такое работало кто-то должен написать полный
сборщик мусора. В этом нет ничего невозможного, есть лишь текущая
ненужность для типичных применений :)
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
