Ну, нужно ли таскать или просто они лежат несобранные (мёртвым грузом) — это ещё надо разобраться в каждом конкретном случае.

Но вообще, без value type'ов от развесистых структур данных, увы, в Java не приходится ждать ничего хорошего. Если у вас ключ long и значение — long (а эффективно Long), то в хэшмапе вы на каждые 16 полезных байтов теряете 3 заголовка объектов «бесполезных», и сравнение с языками с плотной упаковкой (go) как-то становится не очень корректным, увы.

Тем не менее, результат ZGC мне очень понравился, буду пробовать её в новом проекте, надеюсь не подведёт )

И я ещё не проснулся — к трём заголовкам объектов ещё и три указателя. В общем, тоска.

Надо вообще наших опсов палочкой потыкать, что бы они погоняли QA-платформу на новых технологиях, может и правда стоит того, а то очень уж консервативные они у нас. На память нам наплевать, нас STW волнует, но может и с ним лучше?

про производительность чего мы сейчас говорим? и про какие метрики?

на глаз — лучшего стартапа чем с native image ожидать наверное слегка оптимистично

latency для короткобегущих програм - будет я думаю примерно такой же или лучше в native image
peak-performance -- будет лучше в jvm, лучше всех скорее всего в GraalVM EE, GraalVM CE по больнице примерно как С2, но там по-разному где-то проседает, где-то сильно лучше. GraalVM EE — практически универсально лучше чем C2 для обычных ворклоадов, всякая математика - не очень понятно, ну и то что специально написано что бы было быстрым на С2 — тоже скорее всего быстрее на С2 (но не факт)

stable state latency — это 1/throughput'a +- GC, что делает выбор GC очень важным

а, еще там для native images есть profile-guided-optimizations которые обычно подразгоняют почти до разогретого джита

это и хотел узнать, спасибо)

это вот те 42 что выше только поподробнее. Мой biased совет — хочется peak performance — GraalVM EE  в помощь, хочется стартап — native image

не хочется писать на go, но хочется что б не было зависимости на jvm — АОТ всяческие в помощь, например GraalVM native image

ну и мерять конечно все-все

а, GC в native image — он слегка простой такой, не очень заточенный под долгоиграющие приложения, там и паузы будут и все

поговаривают что Roman Kennke из Редхата же занимается, по крайней мере коммиты там в oracle/graal идут. Интересно будет посмотреть что получится

мне кажется 22 и 78 это достаточно похожие результаты. сейчас картинку покажу

тогда не очень понятно как quarkus с native image для обычных веб сервисов собирается работать

135мб vs 35мб памяти с native image, ценой пауз и отказ от рефлексии?

для обычных веб сервисов - quarkus я так понимаю запускается на jvm и отлично себя чувствует, нет?

да) но они же делают акцент на GraalVM