Сборка мусора

[Vitamin]

Это детали реализации данных конкретных технологий. Существуют и другие подходы. Можно выбрать более подходящий.
Известно, что среды со сборкой мусора плохо работают поверх платформ с монопольным захватом памяти. Они либо захватывают очень много памяти, притесняя другие программы (а в системах с виртуальной памятью с подкачкой могут приводить к трэшингу), либо вынуждены использовать более медленные копирующие уплотняющие сборщики мусора, чтобы освобождаемую из под мусора память можно было сливать в большие блоки и отдавать нижележащей системе.

необходимо учитывать специфику спека. предложенная GriV'ом и мной система работы с памятью базируется на следующем- для кучи выделяется большой кусок памяти (сплошной естесно) и просто рулится стандартным системным менеджером кучи, который не поддерживает сборку мусора. а разработчик имеет возможность прикрутить к этому блоку любой другой менеджер. хоть с автоматической сборкой подоходнего налога. но это уже другое дело.

Я совершенно не могу себе представить, как можно на Speccy запустить параллельно несколько сборщиков мусора. Ведь каждому понадобится собственная память "под мусор". А памяти и так не хватает. Поэтому - если сборку мусора реализовывать - но на самом низком уровне исполнения. Чтобы все использовали один сборщик мусора.
А насколько ресурсоёмкая?

считай- в минимально возможной конфигурации- один процесс-сборщик мусора для всех процессов, использующих "навороченный" менеджер кучи. плюс дополнительная память в каждой куче для хранения указателей на выделенные блоки- еще одна прослойка, которой ты так боишься %)

Если предположить, что вся память полностью заполнена указателями, и нет никаких других данных, то сборщику мусора придётся просканировать лишь один раз всю память. В действительности же помимо указателей в памяти находятся также полезные данные, а доля указателей невелика. Можно ожидать, что сборщик мусора будет работать доли секунды.

советую почитать статьи по ускорению работы с памятью для ЯВУ, не поддерживающих сабж

Опять же - насколько?
Загрузив указатель из памяти в регистры можно потом многократно обращаться к блоку памяти, пока указатель находится в регистрах.

А как происходит при "обычном программировании"? Откуда адреса появляются в регистрах?

сравни:
call allocate ;hl-addr
ld (block1),hl
ld de,to
ld bc,len
ldir ;something like this

или

call allocate
ld (block1),hl
ld a,(hl)
inc hl
ld h,(hl)
ld l,a
ld de,to
ld bc,len
ldir

вроде мелочь, а неприятно.

А как происходит без сборки мусора?
Классические алгоритмы управления динамической памятью тоже при каждом выделении перебирают список свободных блоков, выбирая подходящий. Это тоже в плохих ситуациях может оказаться долго.
Ну так ведь речь не о начинающих программистах. Имея дисциплину, можно потом "правильно программировать" и со сборщиком мусора.

сравним еще раз:
без сборщика:
при выделении происходит перебор всех блоков и выбор первого подходящего или наиболее подходящего (две разные стратегии выделения памяти)
при освобождении просто происходит вставка в связный список описателя свободного блока

со сборщиком:
при выделении (см. пред. вариант)
процедура освобождения вызывается только при отсутствии необходимости в выделенном блоке и совпадает с аналогичной процедурой пред. варианта.
НО! затраты (периодические) на просмотр _всего_ списка блоков для поиска кандидатов на удаление. единственное облегчение- просматривается не список блоков, а список указателей на блоки (а хрен редьки, как известно, не слаще %) )

(Бонусный вопрос: какие языки больше дисциплинируют: типизированные или бестиповые?)

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