История изменений
Исправление den73, (текущая версия) :
(c) Википедия
Если почитать статью дальше, там расшифровано. Причём именно так, как это понимаю я. «Т.е. в 5-й строке невозможно ни получить доступ к первым 9 объектам, ни удалить их.» И далее - сборка мусора как способ избавиться от утечек памяти. Т.е., можно сказать, что в Википедии недостаточно чёткое определение, при том, что сама статья правильная. Просто больше мне сослаться было не на что.
В нормальных браузерах промежуточные данные и неактивные страницы лежат в файлах, а не в памяти.
Так и было в ДОСЕ. Код программы в оверлеях, файлы редактора в памяти. Потом появилась виртуальная память и программисты вздохнули свободно. Если же ты говоришь о надёжности, то какая разница, что у тебя закончится - место в памяти или место на диске? Надёжный в этом смысле браузер - это браузер, способный просматривать ограниченное количество страниц ограниченного размера.
Он роняет, так как для самого GC требуется память пропорциональная количеству собираемых элементов. Кстати, хотя бы в принципе, бывают GC с постоянным объёмом используемой памяти? Счётчик ссылок добавляет по счётчику на каждый объект, такой как в SBCL — строит множество удаляемых объектов в процессе сбора.
Просто нужно посчитать максимальный объём памяти, занимаемый в момент GC и соответственно ограничить выделение памяти. Скажем, есть у тебя гигабайт - запрещай дальнейшее выделение после 512 Мб.
В какой задаче нельзя?
Например, ты не сможешь реализовать Common Lisp. А любая достаточно сложная программа, как известно, содержит...
Исходная версия den73, :
(c) Википедия
Если почитать статью дальше, там расшифровано. Причём именно так, как это понимаю я. «Т.е. в 5-й строке невозможно ни получить доступ к первым 9 объектам, ни удалить их.» И далее - сборка мусора как способ избавиться от утечек памяти. Т.е., можно сказать, что в Википедии плохое определение. Просто больше мне сослаться было не на что.
В нормальных браузерах промежуточные данные и неактивные страницы лежат в файлах, а не в памяти.
Так и было в ДОСЕ. Код программы в оверлеях, файлы редактора в памяти. Потом появилась виртуальная память и программисты вздохнули свободно. Если же ты говоришь о надёжности, то какая разница, что у тебя закончится - место в памяти или место на диске? Надёжный в этом смысле браузер - это браузер, способный просматривать ограниченное количество страниц ограниченного размера.
Он роняет, так как для самого GC требуется память пропорциональная количеству собираемых элементов. Кстати, хотя бы в принципе, бывают GC с постоянным объёмом используемой памяти? Счётчик ссылок добавляет по счётчику на каждый объект, такой как в SBCL — строит множество удаляемых объектов в процессе сбора.
Просто нужно посчитать максимальный объём памяти, занимаемый в момент GC и соответственно ограничить выделение памяти. Скажем, есть у тебя гигабайт - запрещай дальнейшее выделение после 512 Мб.
В какой задаче нельзя?
Например, ты не сможешь реализовать Common Lisp. А любая достаточно сложная программа, как известно, содержит...