Value Classes в JDK 28: почему компилятору все еще нужна поддержка
Value Classes Still Need Compiler Sympathy
JEP 401, важная веха проекта Valhalla, включен в JDK 28 как предварительная функция. Value-классы позволяют JVM выбирать подходящее представление данных, отказываясь от идентичности, что открывает новые возможности для оптимизации. Однако, как показывает автор на трех примерах, производительность не гарантирована: для изменяемых полей требуется атомарное обновление, что мешает уплощению; скаляризация и устранение аллокаций возможны только при определенных условиях; а при мегаморфных вызовах из-за стирания типов JVM вынуждена материализовывать значения, что может привести к регрессу. Автор призывает не считать value-классы панацеей и понимать их ограничения.
Я хочу, чтобы value-классы были не просто магией, поэтому сегодня я покажу, на что JVM способна прямо сейчас и где ее пределы.
- DarkNova6
Хороший технический обзор, и я полностью согласен с мыслью, высказанной в заключении:
```
Объявление value-класса — это в первую очередь семантическое решение. Оно сообщает нашим коллегам-программистам, что его экземпляры полностью определяются своим состоянием и не нуждаются в идентичности. Такая более ясная модель сама по себе ценна! Дополнительная свобода JVM оптимизировать представление этих значений — приятный бонус.
```
Многие разработчики, похоже, думают, что "value — и вперёд", но на самом деле всё гораздо тоньше, и идея должна заключаться не в том, чтобы думать о "производительности", а в том, чтобы думать о природе ваших данных. По крайней мере, это встраивает некоторые ключевые уроки DDD прямо в язык. Я рад, что разрывы (tearing) не включены по умолчанию именно по этой причине.
Java всегда была языком, ориентированным на простоту использования библиотек, с большим доверием к автору библиотеки и сильной инкапсуляцией. Теперь эксперты могут получить значительно большую производительность от JVM, а более скромные программисты защищены от создания багов, которых они не ожидают.
- aatd86
Конечно, нуждаются, независимо от языка. Именно поэтому у нас есть, например, интернирование строк. :)
- ferrule
Здесь основную работу выполняет анализ убегания (escape analysis). Пока он не полностью надёжен, вы всё ещё гадаете о выделении памяти.
- pan_lid
Анализ убегания в JVM всегда был ненадёжным. Приятно видеть, что он становится более предсказуемым.
- dist-epoch
С момента создания Java обещала: "не беспокойтесь о низкоуровневых вещах, таких как классы значений и ссылочные классы, Достаточно Умный Компилятор автоматически выберет лучший вариант, исходя из вашего кода и профилирования во время выполнения". Что изменилось, почему вдруг они принимают фичи из C++, которые явно исключили?