Value Classes は依然としてコンパイラの支援を必要とする
Value Classes Still Need Compiler Sympathy
JDK 28のプレビュー機能として統合されたJEP 401（Value Classes）は、値クラスにアイデンティティを持たせないことでJVMに最適化の自由を与えます。しかし、すべてのクラスを値クラスにすれば性能が向上するわけではなく、場合によっては参照表現の方が高速なこともあります。本稿では、不変性によるフラット化、スカラー化による割り当て除去、型消去による動的ディスパッチでのマテリアライズという3つの例を通して、JVMが現在可能な最適化とその限界を示します。特に、値クラスが逆に性能を悪化させるケースを実例で解説し、コンパイラの支援が不可欠であることを明らかにします。
値クラスはJVMにより多くの意味情報と自由度を与えますが、それでもコンパイラの支援なしには、その潜在能力を引き出すことはできません。
HNでの議論
45- DarkNova6
優れた技術概要であり、最後の結論の趣旨に完全に同意します：
```
値クラスを宣言することは、何よりもまず意味論的な決定です。それは、そのインスタンスが完全に状態によって定義され、アイデンティティを必要としないことを仲間のプログラマーに伝えます。その明確なモデルはそれ自体が価値があります！JVMがそれらの値の表現を最適化する追加の自由を得られることは、歓迎すべきボーナスです。
```
多くの開発者は「値が来れば broom だ」と考えているようですが、真実ははるかに微妙であり、考え方としては「パフォーマンス」ではなく、基盤となるデータの本質について考えるべきです。少なくとも、これによりコアなDDDの教訓が言語に直接組み込まれます。まさにこの理由から、tearingがデフォルトでオンになっていないことを嬉しく思います。
Javaは常にライブラリを使いやすくすることに重点を置き、ライブラリの作者と強力なカプセル化に大きな信頼を置く言語でした。今や、専門家はJVMから大幅にパフォーマンスを引き出せる一方で、より謙虚なプログラマーは予期しないバグを生み出すことを避けられます。
- aatd86
もちろん、言語に関係なく必要です。例えば、文字列インターンがその一例です。:)
- ferrule
ここで主要な役割を果たしているのはエスケープ解析です。それが完全に信頼できるようになるまでは、割り当ては依然として推測の域を出ません。
- pan_lid
JVMのエスケープ解析はこれまで当たり外れが大きかった。それがより予測可能になるのは良いことだ。
- dist-epoch
Javaが作られて以来、その売り文句は「値クラスや参照クラスといった低レベルのことを心配するな。十分に賢いコンパイラが、コードと実行時プロファイリングに基づいて最適な選択を自動的に行うだろう」というものでした。
何が変わったのか、なぜ彼らは明示的に除外していたC++の機能を突然採用するのか？