Комментарии 13
Интересен выбор Shenandoah vs ZGC — кто где лучше.
Ещё бы сотрудник Oracle про Shenandoah написал :-) А если по теме - надо поискать обзоры. Тут правильно выбрать способ тестирования ещё надо. 1800$ за Specjbb не всем хочется выкладывать, а изобретать свой всеобъемлющий набор тестов долго. Вот, например, есть некоторые тесты всех GC. Давно делались, но, возможно будут полезны.
Рекомендую попробовать https://github.com/corretto/heapothesys
Для начала, кто не крэшнулся, тот и молодец!
Поправьте меня, если я не прав, но по-моему, главная проблема Java в том, что она слишком много откладывает в кучу :). Даже самый простой объект из пары integer полей породит аллокацию. Очень мало делается на стеке.
Отсюда и вечная борьба за производительность gc. В отличие от того же Golang, где gc прост, но его вполне хватает, потому что убирать не так много надо
Да, наверное и это тоже. Поэтому делают Project Valhalla, например. И если вас не пугает английский с французским акцентом, есть доклад 2019 года, где рассказывается прям вообще про неочевидные сложности с перемещением объектов из кучи на стек. Мне прямо очень зашло.
С включённым в JVM Escape analysis возможна оптимизация когда короткоживущий объект не попадает в кучу (даже в молодое поколение), а помещается на стеке.
да, вас надо поправить, jvm умеет убирать аллокацию и делает это вполне хорошо, более того даже сильно лучше go. как убирает: у вас есть класс типа вектор, с конструктором, мат методами, где-то к вам попадают координаты и вам нужно узнать длину вектора, вы вызываете конструктор и потом метод у созданного объекта. так вот через 10к вызовов после работы jit у вас не будет создаваться объект. чтобы эта оптимизация не сработала у вас должен быть долгоживущий объект и очень сложный код. а так итераторы и т.д. - всё это идёт в лёт, никаких объектов не создаётся.
гонял для примера этот бенчмарк на 17-ой: https://github.com/Mark-Kovalyov/CardRaytracerBenchmark - всё прекрасно инлайнится, сборка мусора происходит в фоне без каких-либо задержек основного потока. там же люди измеряли реализацию на go и она оказалась кажется в 2 раза медленнее чем java! В принципе это чисто вычислительный код с классом вектор, т.е. по большей части бенчмарк gc и jit и gc go проигрывает с треском. Проблема эта вполне известная, разработчики jvm потратили много сил и лет, чтобы сделать то, что есть, и ничего этого в go нет, сборщик мусора у него сильно проще. Просто так взять go и надеяться, что всё заработает быстрее не стоит, с его сборщиком мусора нужно дважды подумать прежде чем создавать объект
Немного оффтоп. Интересно, а проект Loom будет встраиваться в новые jdk
В смысле - "встраиваться"? Планируется, что это будет частью JVM. Когда до ума доведут. Вот тут все написано же.
Так уже (как preview).
Прогресс GC от JDK 8 до JDK 17