Самодельный сборщик мусора для OpenJDK

[bgnx]

Интересно а как быстро будет работать такой сборщик мусора если допустим взять на амазоне сервер с 4 терабайтами оперативки и аллоцировать десять миллиардов объектов которые будут ссылаться друг на друга (реляции между сущностями)?

[olegchir]

А вы напишите, попробуйте и нам расскажете! :-)

[tsypanov]

Epsilon GC реализует только «выделение», а «освобождением» не занимается вообще.

Интересный подход. Краем уха я когда-то слышал о подходе с выключенной сборкой мусора: множество одинаковых приложений запускается в кластере, при этом каждая отдельная ВМ запускается без сборщика, т. е. паузы отсутствуют вообще. Память выедается и неизбежно наступает ООМЕ, после чего ВМ убивается и запускается заново, а запросы перенаправляются на другие приложения того же кластера. Таким образом 100% ЦП занято приложением, не отвлекаясь на мусор.

Получается, с Epsilon GC можно не собирать свою ВМ для отключения сборщика, а просто запуститься с нужной настройкой.

[tbl]

Обычно лайтовую по-поточную сборку young поколений оставляют, т.к. это несет минимальный оверхед, и дешевле, чем затраты, требуемые на высвобождение памяти со стороны ядра после падения и последующий рестарт jvm. Да еще и в виде приятного бонуса реже часть полезной несохраненной работы выкидывается насмарку.

[tsypanov]

Тоже интересный подход.

[mayorovp]

Это, на самом деле, не очень хороший подход: как минимум, теряется используемая JIT статистика, из-за чего эти 100% ЦП используются далеко не со 100% эффективностью.

Вот более подробно: https://habr.com/ru/post/321856/#comment_10071730
И вот ещё хорошее возражение против такого подхода: https://habr.com/ru/post/321856/#comment_10073242

[Maccimo]

Что-то не вижу Шипилёва среди докладчиков.
А ведь после статьи с рекламой конференции в подвале ожидаешь, что он в этом списке присутствует.

[dim2r]

Интересно, были ли попытки написать сборщик, который работает в режиме ядра и имеет доступ к физической памяти и всем наворотам ring0?