Які алгоритми стоять за низькою паузою GC?

Деякі мови, для прикладу java, ввели низьку паузу GC.

Ці GC можуть виконати більшу частину роботи, не призупиняючи весь світ. Це, очевидно, є досить важкою проблемою, оскільки вона потребує аналізу пам’яті, коли потік її модифікує, в результаті чого дані, які можна використовувати на початку процесу, а не більше, коли він закінчується, або дані, які здаються мітками, а тому що посилання було переміщено в пам’яті і ніколи не з’являлося там, де шукав GC.

Отже, який алгоритм (и) стоїть за цим?

Дослідницькі роботи чи посилання на справді технічну статтю вважатимуться вагомою відповіддю, оскільки ця тема справді технічна.

Отже, який алгоритм (и) стоїть за цим?

Це в основному алгоритм розмітки і розгортки, який "просто" працює одночасно в окремій потоці.

Щодо дослідницьких робіт на цю тему:

• Дуже сумісний збір марк і підмітання сміття без тонкозернистої синхронізації

• Одночасний колектор зчитування гарбабе (містить посилання на два документи, один перелічений нижче)

• Реалізація сміттєвого збирача сміття для Java

• Портативний, ненав’язливий збір сміття для багатопроцесорних систем (Doligez Leroy, презентація Powerpoint)

• Збір сміття на ходу: вправа у співпраці (автор: Edsger Wybe Djikstra)

Наскільки я розумію, збирач сміття Java G1 використовує так звані купи регіонів, щоб уникнути пауз усього світу. Як я бачу, це те, що хоча одна з областей заблокована GC, що виконує очищення, розподіл пам'яті здійснюється в іншому регіоні.

Ось пояснення від Джеремі Менсона :

Принцип простий: збирач розбиває купу на регіони фіксованого розміру і відстежує живі дані в цих регіонах. Він зберігає набір покажчиків - "запам'ятовується набір" - в і з регіону. Коли GC вважається необхідним, він спочатку збирає регіони з меншою кількістю живих даних (отже, "спочатку сміття"). Часто це може означати збір цілого регіону за один крок: якщо кількість покажчиків на регіон дорівнює нулю, то для цього не потрібно робити позначку чи підмітку ...

• Ось технічний документ від інженерів Sun, що пояснює їх дизайн: Сміття - Перша колекція сміття

IBM JVM в реальному часі використовує сміттєзбірник під назвою Metronome, який розбиває діяльність GC на дискретні кванти і перемежовує їх при обробці додатків. Таким чином, замість періодичних (і недетермінованих) загальносвітових пауз GC, програма замість цього працює трохи повільніше, тоді як GC робиться паралельно.

Там інша GC , що робить динамічну дефрагментацію і відповідає вимогам жорсткого реального часу, але тільки посилання я можу знайти тут (потрібна членство ACM).

Цікавим одночасно збирачем сміття в реальному часі є stopless . Він використовує традиційний підхід для розмітки, але розроблений для використання в багатопроцесорних системах і підтримує одночасне багатопотокове безблокове замовлення.

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

Я б запропонував для мутації, що вони реалізують певну форму копіювання під час написання, щоб повідомити GC про зміну.