LINUX.ORG.RU

феодально-демоническая сборка мусора

 


0

1

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

Обычно предполагается, что есть только эта последняя куча, а кучек помельче для отдельных нитей нет, только стеки (и thread local storage там же на стеке).

Что мешает сделать разные трассировщики для разных областей?

Могут ещё сказать, мол, что есть процессы - и вот как раз у них кучи независимые. Но при этом все ругаются, что distributed garbage collection не работает.

Предыдущее обсуждение скатилось в терминологический спор (про трассировку и подсчёт количества ссылок). А хотелось бы обсудить это всё в терминах графов. Объекты где-то находятся (лежат в куче), они могут быть обнаружены каким-то способом, независимым от наличия ссылок на них. Достижимые от корневых ссылок объекты образуют одну часть графа, недостижимые объекты - другие части графа. Хотелось бы описать, что такое «области» в каких-нибудь более формализованных терминах. Есть же, к примеру, слово «шарнир» и другие. Может быть можно как-то автоматизированно делить на них граф живых объектов автоматически?

★★☆

Последнее исправление: Einstok_Fair (всего исправлений: 4)

Не понял вопрос, пожалуйста, попробуйте переформулировать.

vzzo ★★★
()

Обычно предполагается, что есть только эта последняя куча, а кучек помельче для отдельных нитей нет, только стеки (и thread local storage там же на стеке).

Кучки поменьше называются pool. Реализуются через создание массива и выделение памяти внутри него. GC там либо пользовательский, либо отсутствует и освобождается только pool целиком.

monk ★★★★★
()

Знаете... Если честно, то...

Всё это уже и не раз и не два и даже не три обсуждалось. В разных терминах. И в терминах теории графов в том числе. Думаете, не, Вы первый такой умный? =)))

В качестве «лечения от...» я бы Вам настоятельнейшим образом рекомендовал бы взять и реализовать такой сборщик мусора.

Тогда до Вас дойдёт почему на практике вещи типа Boehm GC применяются в весьма ограниченном числе проектов. Ну и заодно почему jemalloc, Hoard, tcmalloc (это вообще thread caching malloc) и тот же lockless allocator это тоже сравнительно слабо распространённые вещи. От аллокатора памяти-то тоже немало зависит, согласитесь? Потом же эту память как-то зачищать же. Мало её выделить... До Вас дойдут вещи типа memory fragmentation и почему Вам выше советовали обратить внимание на memory pools...

В общем, всё встанет на свои места. Дерзайте, удачи! Как там старина Энгельс-то говаривал? «Практика есть критерий истины»? Ну вот. К коду, сударь!

=)))

Moisha_Liberman ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.