Сборка мусора — корневые узлы

Я обнаружил, что ответ, предоставленный greyfairer, неверен. Среда выполнения JVM не собирает корневой набор из стека, просматривая, какие байт-коды используются для передачи данных в стек. Фрейм стека состоит из 4-байтовых (32-битных) слотов. Каждый слот может быть ссылкой на объект кучи или примитивное значение, такое как int. Когда требуется GC, среда выполнения сканирует стек сверху вниз. Для каждого слота он содержит ссылку, если:

а. Он выровнен по границе 4 байта.

б. Значение в слоте указывает на область кучи (между нижней и верхней границей).

в. Аллокбит установлен. Аллокбит — это флаг, указывающий, выделена ли соответствующая ему ячейка памяти или нет.

Вот моя ссылка: http://www.ibm.com/developerworks/ibm/library/i-garbage2/.

Есть и другие методы поиска корневого набора (не в Java). Например, поскольку указатели обычно выравниваются по границе 4/8 байтов, первый бит может использоваться для указания того, является ли слот примитивным значением или указателем: для примитивных значений первый бит устанавливается равным 1. Недостатком этого является что у вас есть только 31 бит (32-битная арка) для представления целого числа, и все операции над примитивными значениями включают сдвиг, что является очевидным накладным расходом.

Кроме того, вы можете выделить все типы, включая int, в куче. То есть все вещи являются объектами. Тогда все слоты в кадре стека являются ссылками.

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

Например, если функция f1 вызывает функцию f2(int i, Object o, long l), вызывающая функция f1 поместит 4 байта в стек (или в регистр), представляющие i, 4 (или 8?) байтов для ссылка на o и 8 байтов на l. Вызванная функция f2 знает, где найти эти байты в стеке, и потенциально может скопировать ссылку на какой-либо объект в куче или нет. Когда функция f2 вернется, вызывающая функция удалит параметры из стека.

Среда выполнения интерпретирует байт-код и ведет учет того, что она помещает в стек или отбрасывает, поэтому она знает, что является ссылкой, а что примитивным значением.

Согласно http://www.javacoffeebreak.com/articles/thinkinginjava/abitaboutgarbagecollection.html, java использует отслеживающий сборщик мусора, а не алгоритм подсчета ссылок .

HotSpot VM создает карту GC для каждой скомпилированной подпрограммы, которая содержит информацию о том, где находятся корни. Например, предположим, что он скомпилировал подпрограмму в машинный код (принцип тот же для байтового кода) длиной 120 байт, тогда карта GC для нее может выглядеть примерно так:

0 : [RAX, RBX]
4 : [RAX, [RSP+0]]
10 : [RBX, RSI, [RSP+0]]
...
120 : [[RSP+0],[RSP+8]]

Здесь [RSP+x] должно указывать расположение стека и R?? регистров. Таким образом, если поток останавливается на инструкции сборки по смещению 10 и выполняется цикл gc, то HotSpot знает, что три корня находятся в RBX, RSI и [RSP+0]. Он отслеживает эти корни и обновляет указатели, если ему нужно переместить объекты.

Формат, который я описал для карты GC, предназначен только для демонстрации принципа и, очевидно, не тот, который на самом деле использует HotSpot. Он неполный, потому что не содержит информации о регистрах и слотах стека, которые содержат примитивные живые значения, и неэффективно использовать список для каждого смещения инструкции. Есть много способов, которыми вы можете упаковать информацию гораздо более эффективным способом.