jugnsk JUGNsk Meetup #14 (24.04.2020)

Shenandoah GC 2.0 (часть 1)

img

Одна из главных проблем больших Java-приложений — это cбо…​ рка мусо…​ ра. Хранение больших куч данных, активно фрагментирующие приложения и прочие выпадающие из гипотезы о поколениях нагрузки приносят ещё больше проблем. Промышленные GC давно решили первую большую часть проблемы сборки, concurrent marking — выяснение графа объектов без долгой остановки приложения. Shenandoah — новый сборщик мусора, который пытается решить вторую большую часть головоломки, а именно перемещение объектов без остановки приложения, тем самым сбивая паузы ещё больше. Эта часть доклада об особенностях дизайна и реализации Shenandoah, достоинствах, которыми можно гордиться, и недостатках, с которыми приходится мириться.

После того, как мы разобрались с главными фазами и превратили их в конкурентные, паузы в основном стали определяться более короткими, но всё равно зачастую stop-the-world активностями между большими конкурентными эпохами. В них придётся заниматься всяким: сканировать GC roots, взаимодействовать с языковыми фичами, которые в курсе про существование GC (например, weak references), разбираться с проблемами в реализации safepoint-ов, менеджить память и как-то делиться ей с ОС и т.п. Вторая часть доклада ныряет в кроличью нору проблем, с которыми вынужден столкнуться низкопаузный GC вроде Shenandoah, размышляет, что можно сделать с этими проблемами на уровне JVM, а также над тем, что могут предпринять предусмотрительные разработчики низкопаузных Java-систем, зная об этих граблях.