4.2 KiB
| aliases | tags | date | zero-link | parents | linked | |||
|---|---|---|---|---|---|---|---|---|
|
2023-11-07 |
|
|
Этот алгоритм пытается собирать мусор в то же время, когда работает приложение, чтобы уменьшить влияние сбора мусора на производительность приложения.
Marking
В этом и заключается проблема: приложение активно используется, а значит намного сложнее определять живые/мертвые объекта, а еще сложнее эвакуировать, то есть переносить эти объекты.
Мы начали обходить граф, и в момент обхода ссылка из серого объекта пропала, а в черном (который мы уже посетили), ссылка появилась.
Есть 2 решения, которые позволяют решить эту проблему. Оба решения перехватывают запись.
Обычно при таком подходе мы имеем 2 паузы:
- Init Mark. Скорость зависит от размера Root Set.
- Остановить мутатор, чтобы избежать состояния гонки
- Покрасить весь Root Set в черный
- Взвести SATB/Incremental Update (IU) барьеры в готовность
- Final Mark. Скорость зависит от размера Root Set и длины очередей.
- Остановить мутатор, чтобы избежать состояния гонки
- Слить остатки из SATB/Incremental Update (IU) очередей
- Доделать маркировку из этих остатков и изменений в root set-е.
Наблюдения Алексия Шипелева:
- Хорошо сделанный StopTheWorld GC побьет хорошо сделанный Concurrent GC по пропускной способности
- Даже если GC не работает, вы платите за барьеры.
Copy Collector
В отличие от StopTheWorld здесь возникают проблемы. Теперь мы пытаемся переносить объекты во время работы приложения, а значит приложение может "застать нас врасплох", когда мы будем в процессе переноса объекта.
Здесь нам помогают Brooks pointers, дополнительное перенаправление.
Выводы
Минусы:
- Необходимо поддерживать постоянную консистентность heap, так как приложение может обратиться к данным в любой момент времени. Для этого обычно используются барьеры, которые оказывают влияние на производительность приложения.
- Ресурсы железа уходят на работу GC.