Некоторые моменты о реализации сборщика мусора

Question

Я пытаюсь реализовать простой язык программирования. Я хочу, чтобы пользователю этого не нужно было управлять памятью, поэтому я решил реализовать сборщик мусора. Самый простой способ, который я могу придумать после проверки некоторых материалов, выглядит следующим образом:

Существует два типа зон кучи. Первый - для хранения больших объектов (более 85 000 байт), другой для небольших объектов. В следующем я использую BZ для первого, SZ для второго.

BZ использует алгоритм отметки и развертки, потому что перемещение большого объекта дорого. Я не компактен, поэтому будет фрагментация.

SZ использует поколения с меткой-компактностью. Существует три поколения: 0, 1 и 2. Запросы на распределение направляются непосредственно в поколение 0, а когда поколение 0 заполнено, я сделаю сборку мусора на нем, выживаемость будет повышена до поколения 1. поколение 1, а поколение 2 будет тоже сделать сборщик мусора когда полностью.

Когда виртуальная машина запускается, она будет выделять большую память из ОС, которая будет использоваться в качестве зоны кучи в виртуальной машине. BZ и каждое поколение в SZ будут занимать фиксированную часть памяти и когда запрос на распределение не может быть удовлетворено, виртуальная машина выдаст ошибку OTM (вне памяти). У этого есть проблема: при запуске виртуальной машины даже для запуска программы на нее должна быть только небольшая память, но она все еще использует много. Лучший способ для виртуальной машины получить небольшой объем памяти из ОС, а затем, когда программе потребуется больше памяти, виртуальная машина получит больше от ОС. Я собираюсь выделить большую память для поколения 2 в SZ, а затем скопировать все вещи в поколении 2 в новую зону памяти. И сделайте то же самое для BZ.

Другая проблема возникает, когда BZ заполнен и SZ пуст, я бы глупо не смог удовлетворить большой запрос на размещение объектов, хотя у нас на самом деле имеется достаточно свободного размера кучи для большого объекта в SZ. Как справиться с этой проблемой?

Answer 1

Я пытаюсь понять вашу методологию. Поскольку вы полностью не указали свою стратегию, у меня есть некоторые предположения.

ПРИМЕЧАНИЕ: Ниже приводится мой гипотетический анализ и может быть практически невозможным. Поэтому, пожалуйста, пропустите ответ, если у вас нет времени.

Вы пытаетесь использовать Generational GC с изменениями; Существуют классификации 2-х типов

(1) большой размер объектов, BZ и

(2) небольшой размер объекты SZ.

SZ выполнения поколений GC с уплотнением (CMS)

Из выше понимания, мы знаем, что SZG2 долго жил объектов.Я ожидаю, что GC в szG2 не так часто, как SZG1 или SZG0 так долго жил объект, как правило, как правило, живут дольше, тем меньше мертвый сбор и размер SZG2 будет больше, как время истечет, так GC'ing принимает много времени, проходящего по всем элементам, так что частые GC на SZG2 менее производительный (длинный всплеск GC, поэтому заметная задержка для пользователя) по сравнению с SZG1 или SZG0.

Аналогичным образом для BZ может потребоваться большая потребность в памяти (поскольку большой объект занимает больше места). Поэтому для того, чтобы обратиться к вам запрос

"The other problem occurs when the BZ is full and SZ is empty, I would be silly not be able to satisfy a big object allocation request even though we in fact have enough free heap size for the big object in SZ. How to deal with this problem?"

Поскольку вы сказали, что «когда программа требует больше памяти виртуальная машина получит больше от ОС»

У меня есть небольшое представление, не может быть продуктивны или могут быть невозможны для реализации и полностью зависят от вашей реализации структуры GCHeap. Пусть ваша виртуальная машина выделяет память, как следует

Coming возможности (я позаимствовал идею из «сегментов памяти программы», как показано ниже) ниже можно на низком уровне.

Как показано на рисунке выше структуру GCHeap должен быть определен таким образом, что SZG0 и БЗ расширить в сторону друг от друга структуры, реализующей .Для GCHeap упоминается в рисунке в , Рисунок b Нам необходимо иметь правильное согласование роста памяти в зонах SZG [0-2] размер и BZ.

Так что, если вы хотите разделить кучи для применения в нескольких куч, то вы можете складываете рисунка A над фигура B для уменьшения фрагментации (когда я говорю фрагментация it means "when the BZ is full and SZ is empty, I would be silly not be able to satisfy a big object allocation request even though we in fact have enough free heap size for the big object in SZ.").

Так эффективная структура будет

  B 
      | 
      B 
      | 
      B 
      | 
      B 
      | 
      A 

Теперь его полностью зависит от эвристики, чтобы решить, следует ли рассматривать структуру данных GCHeap в нескольких GCHeap структур, как GCHeapA, GCHeapB или взять его в одну кучу на основе требований.

Если вы не хотите иметь несколько куч, то вы можете использовать рисунок А с небольшой поправкой на Setting base address of **SZG2** to top of heap

Ключевой причиной Рисунок A выглядит следующим образом: мы знаем, что SZG0 прибудете GC'ed часто так что он может иметь больше свободного пространства по сравнению с SZG1 и SZG2, так как мертвые объекты удаляются и выжила объект получает переехал в SZG1 и SZG2 .so если распределение BZ больше он может вырасти к SZG0.

В фигуре базовый адрес SZG1 и SZG2 являются contigious, потому что SZG2 более склонна к ошибке из памяти в качестве объекта старого поколения, как правило, живут дольше и GC'ing оленья кожа подметать много (ПРИМЕЧАНИЕ: это только мое предположение и мнение) SZG2 хранится в обратном направлении.