Исходное сообщение
"Выпуск Java SE 20" Отправлено Аноним, 22-Мрт-23 16:25
У языков с GC, в дизайне которых заложено 99% вещей отправлять в heap, в итоге дикая фрагментация кучи и под высокой нагрузкой становятся ощутимым влияние кэш-промахов, возникающих из-за вышеупомянутой фрагментации (нарушение принципа локальности). Разработка на языках типа C/C++, Rust отлично демонстрирует, что необходимость в куче возникает, когда нужно: 1) Держать в памяти что-то сильно большое 2) Держать в памяти какой-то shared объект, к которому должен быть организован параллельный доступ из нескольких потоков 3) Когда размер аллоцируемой памяти не может быть вычислен на этапе компиляции, поэтому нужна динамическая память Во всех остальных случаях, если разработчик отдает себе отчёт, что стек вызовов не безразмерный и разумно аллоцирует на стеке небольшие структуры/массивы структур, то оказывается, что чаще всего большую часть бизнес-логики можно описать, через такие вот "автоматические" переменные, которые освободят место сразу после выхода из блока кода, heap pressure ощутимо снижается -> у GC меньше работы, он меньше перемещает данные в памяти из одного места в другое и делает меньше stop-the-world. Насколько знаю, в Java-сообществе в курсе проблемы, есть Project Valhalla, в рамках которого разрабатываются т.н. value types (по сути, "плоские" объекты, массивы которых JVM будет уметь хранить как массив структур, а не массив ссылок на объекты)/ P.S. Ближайший конкурент Java, С#, имеет ключевое слово stackalloc, которым, в общем-то, довольно успешно пользуются в чувствительных к производительности .NET-решениях.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> У языков с GC, в дизайне которых заложено 99% вещей отправлять в > heap, в итоге дикая фрагментация кучи и под высокой нагрузкой становятся > ощутимым влияние кэш-промахов, возникающих из-за вышеупомянутой фрагментации (нарушение > принципа локальности). > Разработка на языках типа C/C++, Rust отлично демонстрирует, что необходимость в куче > возникает, когда нужно: > 1) Держать в памяти что-то сильно большое > 2) Держать в памяти какой-то shared объект, к которому должен быть организован > параллельный доступ из нескольких потоков > 3) Когда размер аллоцируемой памяти не может быть вычислен на этапе компиляции, > поэтому нужна динамическая память > Во всех остальных случаях, если разработчик отдает себе отчёт, что стек вызовов > не безразмерный и разумно аллоцирует на стеке небольшие структуры/массивы структур, то > оказывается, что чаще всего большую часть бизнес-логики можно описать, через такие > вот "автоматические" переменные, которые освободят место сразу после выхода из блока > кода, heap pressure ощутимо снижается -> у GC меньше работы, он > меньше перемещает данные в памяти из одного места в другое и > делает меньше stop-the-world. > Насколько знаю, в Java-сообществе в курсе проблемы, есть Project Valhalla, в рамках > которого разрабатываются т.н. value types (по сути, "плоские" объекты, массивы которых > JVM будет уметь хранить как массив структур, а не массив ссылок > на объекты)/ > P.S. Ближайший конкурент Java, С#, имеет ключевое слово stackalloc, которым, в общем-то, > довольно успешно пользуются в чувствительных к производительности .NET-решениях.
	Введите код, изображенный на картинке: