LINUX.ORG.RU

История изменений

Исправление den73, (текущая версия) :

(c) Википедия

Если почитать статью дальше, там расшифровано. Причём именно так, как это понимаю я. «Т.е. в 5-й строке невозможно ни получить доступ к первым 9 объектам, ни удалить их.» И далее - сборка мусора как способ избавиться от утечек памяти. Т.е., можно сказать, что в Википедии недостаточно чёткое определение, при том, что сама статья правильная. Просто больше мне сослаться было не на что.

В нормальных браузерах промежуточные данные и неактивные страницы лежат в файлах, а не в памяти.

Так и было в ДОСЕ. Код программы в оверлеях, файлы редактора в памяти. Потом появилась виртуальная память и программисты вздохнули свободно. Если же ты говоришь о надёжности, то какая разница, что у тебя закончится - место в памяти или место на диске? Надёжный в этом смысле браузер - это браузер, способный просматривать ограниченное количество страниц ограниченного размера.

Он роняет, так как для самого GC требуется память пропорциональная количеству собираемых элементов. Кстати, хотя бы в принципе, бывают GC с постоянным объёмом используемой памяти? Счётчик ссылок добавляет по счётчику на каждый объект, такой как в SBCL — строит множество удаляемых объектов в процессе сбора.

Просто нужно посчитать максимальный объём памяти, занимаемый в момент GC и соответственно ограничить выделение памяти. Скажем, есть у тебя гигабайт - запрещай дальнейшее выделение после 512 Мб.

В какой задаче нельзя?

Например, ты не сможешь реализовать Common Lisp. А любая достаточно сложная программа, как известно, содержит...

Исходная версия den73, :

(c) Википедия

Если почитать статью дальше, там расшифровано. Причём именно так, как это понимаю я. «Т.е. в 5-й строке невозможно ни получить доступ к первым 9 объектам, ни удалить их.» И далее - сборка мусора как способ избавиться от утечек памяти. Т.е., можно сказать, что в Википедии плохое определение. Просто больше мне сослаться было не на что.

В нормальных браузерах промежуточные данные и неактивные страницы лежат в файлах, а не в памяти.

Так и было в ДОСЕ. Код программы в оверлеях, файлы редактора в памяти. Потом появилась виртуальная память и программисты вздохнули свободно. Если же ты говоришь о надёжности, то какая разница, что у тебя закончится - место в памяти или место на диске? Надёжный в этом смысле браузер - это браузер, способный просматривать ограниченное количество страниц ограниченного размера.

Он роняет, так как для самого GC требуется память пропорциональная количеству собираемых элементов. Кстати, хотя бы в принципе, бывают GC с постоянным объёмом используемой памяти? Счётчик ссылок добавляет по счётчику на каждый объект, такой как в SBCL — строит множество удаляемых объектов в процессе сбора.

Просто нужно посчитать максимальный объём памяти, занимаемый в момент GC и соответственно ограничить выделение памяти. Скажем, есть у тебя гигабайт - запрещай дальнейшее выделение после 512 Мб.

В какой задаче нельзя?

Например, ты не сможешь реализовать Common Lisp. А любая достаточно сложная программа, как известно, содержит...