В чем принципиальная разница между эвакуацией и уплотнением в сборке мусора?

Я прочитал большое количество документации о HotSpot GC Java SE 6 и 7. При обсуждении стратегий получения смежных областей свободной памяти представлены два «конкурирующих» подхода: метод эвакуации (обычно применяется на молодой ген), где живые объекты копируются из «из» в пустое «в» и в область сжатия (откат CMS), где живые объекты перемещаются в одну сторону внутри фрагментированной области, чтобы сформировать непрерывный блок использовал неиспользованную память.

Оба подхода пропорциональны размеру «живого множества». Разница в том, что для эвакуации требуется в 2 раза больше места, чем для живого набора, в отличие от сжатия.

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

Верно: эвакуация может выполняться параллельно (где сжатие не может или, по крайней мере, не так легко), но эта черта никогда не упоминается и кажется не столь важной (учитывая, что переназначение намного дороже, чем перемещение).

7 голосов | спросил Vitaliy 30 MonEurope/Moscow2013-12-30T00:37:00+04:00Europe/Moscow12bEurope/MoscowMon, 30 Dec 2013 00:37:00 +0400 2013, 00:37:00

2 ответа


0

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

Это делает GC намного менее параллельным - приложение должно находиться в «GC freeze» в течение более длительного периода времени.

ответил Hot Licks 30 MonEurope/Moscow2013-12-30T00:45:42+04:00Europe/Moscow12bEurope/MoscowMon, 30 Dec 2013 00:45:42 +0400 2013, 00:45:42
0

Уплотнение больше подходит в тех случаях, когда ожидается, что число исправляемых объектов будет небольшим (например, генерация с постоянным доступом), поскольку после нескольких циклов GC долгоживущие объекты, как правило, занимают нижнюю часть кучи и, следовательно, требуется меньше работы. должно быть сделано коллекционером. Если в таком случае используется копирующий коллектор, который будет работать очень плохо, потому что почти одни и те же уцелевшие объекты из предыдущих циклов придется копировать снова и снова из одного места в другое.

Копирование подходит, когда число восстанавливаемых объектов очень велико (например, молодое поколение), поскольку необходимо копировать очень мало выживших объектов. Если в таком случае используется сжатие, которое может работать плохо, потому что уцелевшие объекты могут быть разбросаны по куче.

Кроме того, как упомянуто в ответе @Hot Licks Копирование сборщика позволяет нам сохранить указатель пересылки, который предотвращает запуск в бесконечный цикл в случае, если другой объект из того же пространства «От» ссылается на уже перемещенный объект.

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

ответил Dev 7 +03002018-10-07T16:33:01+03:00312018bEurope/MoscowSun, 07 Oct 2018 16:33:01 +0300 2018, 16:33:01

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132