Java GC: чому два регіони, що вижили?

Для JVM Sun / Oracle я читав, що алгоритм GC розділяє нове покоління на один регіон Едему та два регіони, що вижили. Мені цікаво, чому два регіони, що вижили, а не тільки один? Альго може продовжувати пінг-понг між Едемом і лише одним регіоном, що вижив (так, як це робиться в даний час між двома регіонами, що вижили); чи є у цього підходу недоліки?

Я вважаю, що реалізація GC JRockit працює більше, як ви пропонуєте, лише з одним простором і одним космосом, що вижив, але не цитуйте мене з цього приводу.

Причиною двох вижилих приміщень HotSpot JVM є зменшення необхідності мати справу з фрагментацією. Нові об'єкти розміщені в космосі Еден. Все добре і добре. Коли він буде заповнений, вам потрібен GC, тому вбивайте застарілі предмети і переміщуйте живі в космос, де виживуть, де вони зможуть дозріти на деякий час, перш ніж бути підвищеними до старого покоління. Поки що все ще добре. Наступного разу, коли у нас не вистачить простору, ми маємо загадку. Наступний GC з’являється і звільняє деякий простір як в Едемі, так і в космосі, що залишився в живих, але місця не суміжні. Так чи краще

1. Спробувати вмістити вцілілих з Едена в отвори в просторі для вижилих, які були очищені ГК?
2. Змістити всі об’єкти в просторі для вижилих вниз, щоб усунути фрагментацію, а потім перенести в нього вижилих?
3. Просто скажіть "вкрутіть, ми все одно все переміщаємо", і скопіюйте всіх тих, хто вижив з обох просторів, в абсолютно окремий простір - другий простір, що залишився в живих, - таким чином, ви отримаєте чистий космос для едемів і вижилих, де ви зможете повторити послідовність на наступному GC?

Відповідь Сонця на питання очевидна.

Роль двох приміщень, що вижили, змінюється після операції незначного збору сміття

Два місця, що вижили. Вони містять предмети, які пережили принаймні один незначний збір сміття, але їм було надано ще один шанс стати недосяжними перед тим, як бути підвищеними до старого покоління. Лише один з них вміщує предмети, тоді як інший більшу частину часу не використовується.

Під час роботи незначного збору сміття будуть позначені предмети, які виявились сміттям. Живі об'єкти в Едемі, які пережили колекцію, копіюються у невикористаний простір для виживання. Живі об'єкти в космосі, що використовується, який отримає ще один шанс на відновлення у молодого покоління, також копіюються у невикористаний космос. Нарешті, живі об’єкти в космосі, що використовується, які вважаються «досить старими», просуваються до старого покоління.

В кінці незначного вивезення сміття два місця, що вижили, міняються місцями. Едем цілком порожній; використовується лише одне приміщення, що вижило; а заповнюваність старого покоління дещо зросла. Оскільки живі об'єкти копіюються під час його роботи, цей тип збирача сміття називається копіювальним збирачем сміття.

Джерело: вище наведені уривки зі сторінки 83 Java Performance , Чарлі Хант та Біну Джон.

Молоде покоління: Це місце, де жили нетривалий час і розділене на два простори:

Простір Eden: нові об'єкти будуть виділені в пул пам'яті. Припущення полягає в тому, що більшість об’єктів отримують розмежування та стають недосяжними незабаром після їх створення. Об'єкти, на які не спрямовано посилання, будуть скопійовані збирачем сміття нового покоління у місця для виживання. Вони можуть бути скопійовані в деяких особливих випадках безпосередньо в пул старого покоління.

Місця для тих, хто вижив: Ці два маленькі приміщення зберігають вижилі об’єкти збору сміття молодого покоління. Об'єкти, що вижили, будуть копіюватися (невелика) кількість разів з одного вцілілого в інший. Це дозволяє збирати урожай наших об'єктів, що не переносяться.

Старе покоління: найбільший пул пам'яті, який повинен зберігати довгоживучі предмети. Об’єкти копіюються в цей пул, як тільки вони залишають місця, що вижили.

Генерування пермаменту: Цей досить невідомий пул зберігає інформацію про всі класи. Для більшості додатків це не потребує уваги. Можливо, його доведеться адаптувати для деяких додатків з багатьма класами. Також може знадобитися певна увага, якщо програма постійно завантажує та розвантажує класи.

Інші переваги:

• Фрагментація пам'яті
• Це покращує продуктивність ГХ

Будь ласка, знайдіть наступні посилання для отримання додаткової інформації, яка допоможе вам зрозуміти більше

http://www.scalingbits.com/javaprimer

http://java.sys-con.com/node/84695

Усі поточні відповіді говорять про фрагментацію пам'яті, це також ще одна причина мати покоління в GC.

Під час виконання записуються всі “старі об’єкти”, які вказують на “нові об’єкти”, це робиться кожного разу, коли поле “покажчика” оновлюється. Потім, коли виконується “незначний” GC, потрібно сканувати лише “нові” об’єкти.

З роками було виявлено, що просто мати «нове» та «старе» недостатньо, і добре мати 3-те покоління, яке має «середній вік».

Які переваги та недоліки копіювання всіх екземплярів покоління з одного простору в інший, порівняно з копіюванням їх у порядку адреси пам'яті до початку простору покоління? Для обробки предметів у порядку, можливо, потрібно буде додати додатковий покажчик на елемент, але усуне потребу в одному з просторів «вижилих».

Двоє вцілілих реалізують алгоритм маркування та копіювання. Вони використовуються в ГХ для молодого покоління. Як згадував Райан у варіанті 3 тут

Куча пам'яті в Java Об'єкти Java, створені в області, яка називається кучи пам'яті. Куча пам'яті створюється під час запуску JVM, куча пам'яті збільшується або зменшується при запуску програми Java. Коли пам’ять купи заповнюється, збирач сміття видаляє невикористані об’єкти, таким чином збирач сміття створює простір для нових об’єктів.

Пам'ять купи поділяється на дві області (або покоління)

1.молодий простір. 2.старий простір.

1.У молодому просторі є Едемський простір для нового Об’єкта, і є два простори вижилих (від і до), ці два простори вижилих завжди однакового розміру.

2. Простір для виживання використовується для зберігання об'єктів виживання. Коли молодий простір стає повним, збирач сміття видаляє невикористані об'єкти, запускаючи спеціальну молоду колекцію, де всі об'єкти, які прожили досить довго в молодому просторі, переміщуються (переміщуються) до старий простір, тим самим звільняючи молодий простір для більшого розподілу об’єктів.

3.Якщо космос Eden заповнений, GC буде працювати, якщо в цьому просторі Eden живуть будь-які об'єкти, вони переміщуються до космосу Survivor

4.У молодому просторі GC зазвичай використовують алгоритм копіювання, який є швидким, щоразу, об'єкти виживання копіюються в один із простору вижилих.

5.Якщо Космос Вижитого заповнений, решта об'єктів, що живуть, безпосередньо копіюються в Старий Космос.

6. У старому космосі GC звичайно використовує компактний алгоритм Mark, який працює повільно, але вимагає менше пам'яті.

7. Коли старий космос стає повним сміттям, там збирається сміття, що називається старою колекцією. У старому просторі об’єкти, що перебувають у режимі тривалого часу, залишаються там.

8. Зникне пам’ять, немає місця для нового Об’єкта, навіть GC зроблено для СТАРОЇ або Пермської частини.

9. Об'єкт переміщується під час збору сміття: eden -> пережив -> tenured (старий простір)