JVM Language Summit 2025 Day 2

Heap flattening for value classes (Paraffin Federica)

Federica は、Project Valhalla の一環として、Jet 401 における 値クラス（value classes） に対する ヒープフラット化（heap flattening） の実装とその利点・課題について解説した。 

ヒープフラット化とは？ 

  • オブジェクトの内容をインスタンスに直接コピーすることで、メモリ使用量を削減し、キャッシュ効率を向上。 
  • 値クラスに適用することで、オブジェクトの識別性と可変性を排除し、効率的なメモリ管理が可能に。 

メリット 

  • GC（ガベージコレクタ）の負荷軽減とメモリ使用量の削減。 
  • キャッシュ局所性の向上により、実行時間が 4.5 秒 → 2 秒に短縮された例も。 
  • ヘッダーやメタデータの排除により、メモリ密度が向上。 

課題とトレードオフ 

  • 非アトミック性：スレッド間で一貫性のないデータが見える可能性。
    • 一時的な解決策として「すべての値型をアトミックにする」方法が検討中。 
  • null 許容性：非 null 型が望ましいが、null を扱うための追加メモリが必要。 
  • C1/C2 コンパイラの混在：C1 は参照を使い、C2 はフラット化された値を直接扱うため、両方の表現を保持する必要がある。 

最適化と将来の方向性 

  • ユーザー指定のアクセスパターンをプロファイリングし、VM がより良いフラット化判断を下せるようにする。 
  • sealed interface 階層のフラット化の可能性を調査。 
  • C1/C2/インタプリタ間の相互作用を明確化し、ポインタとフラットコピーの両立を検討。 
  • ヒープバッファリングや動的型配列の最適化など、さらなる改善が期待される。 

今後の計画 

  •  アクセスパターンのプロファイリング手法を検討。 
  •  sealed interface 階層のフラット化の実現可能性を調査。 
  •  C1/C2/インタプリタ間でのフラット値の扱いを明確化。 

New numeric types in Java (Joe Darcy)

資料はこちら。

https://github.com/jddarcy/SpeakingArchive/blob/master/JVMLS-2025-Numerics.pdf

Oracle の Joe Darcy は、Project Valhalla に関連するvalue classesやtype classesを含む、Java における新しい数値型の導入について解説した。科学技術、教育、AI 分野での数値型の重要性を強調し、言語・仮想マシン・クラスライブラリ全体でのサポートの必要性を訴えた。 

抽象代数学と数値型 

  • モノイド、群、環、体 などの数学的構造を紹介し、それらが Java の型設計やコンパイラ最適化に与える影響を説明。 
  • 例：有限体（finite fields）は楕円曲線暗号などのアルゴリズムに応用されている。 

float16 の導入と教訓 

  • float16 の導入 (Java 24) における設計と実装の課題を共有。 
  • 正確な変換（例：BigDecimal との相互変換）や丸め誤差の管理が重要。 
  • monoid witnessesを使った演算サポートの実装例を紹介。 

複素数・虚数型の設計 

  • 複素数や虚数型の導入に向けた設計課題を議論。 
  • 工学・数学分野での有用性を踏まえ、誤差処理の正確性や演算の可換性を重視。 
  • 複素数の乗算など、演算の正確性と一貫性が求められる。 

実装上の課題と解決策 

  • JLS（Java Language Spec）、JVM、クラスファイル形式など、複数の仕様にまたがる変更が必要。 
  • JNI やシリアライズなどの API にも影響。 
  • 一度の変更で複数の型をサポートできる仕組み を提案。 

最適化と将来の方向性 

  • ユーザー定義型に代数的性質（群・環など）を示す手段 を検討中。 
  • ビッグバイナリ型や変換ルーチンの調整可能性 により、新しい浮動小数点形式の追加を簡素化。 
  • アクセスパターンの動的プロファイリング による最適化の可能性。 

今後の課題 

  •  ユーザー定義数値型に代数的性質（群・環など）を示す手段の検討。 
  •  新しいバイナリ浮動小数点形式を簡単に追加できるよう、調整可能な「ビッグバイナリ型」や変換ルーチンの提供を検討。 
  •  複素数のパラメータ化表現や無限大などの特殊値の扱いを含む数値型モデリングの継続。 

From Final to Immutable (Cimadamore)

Javaにおける final フィールドと「不変性（immutability）」の関係に焦点を当て、final の利点と限界、そしてそれを補完する新しい概念「stable values（安定値）」について解説した。 

Finalフィールドと不変性の基本 

  • final フィールドは、オブジェクトの構築後に変更されないことを保証し、スレッド間での予測可能性を高める。 
  • ただし、リフレクションを使えば final フィールドも変更可能であり、パフォーマンスやセキュリティに影響を及ぼす可能性がある。 
  • Javaでは、C言語の影響で可変オブジェクト (mutable objects) がデフォルトだが、関数型言語（例：Haskell）は不変性 (immutability) を重視する。 

課題：可変オブジェクトと同期の問題 

  • Point や Line のようなクラスで、可変フィールドがあると、スレッド間で不整合が発生する可能性がある。 
  • final フィールドは、JVMによってメモリバリアが適用され、同期なしでの共有が可能になる。 
  • ただしシリアライズなどのフレームワークでは、final をバイパスするための「裏口」が必要になることもある。 

Stable Value API の導入 

  • @Stable アノテーションと Stable Value API により、「一度だけ変更可能」なフィールドを定義可能。 
  • これにより、遅延初期化（lazy initialization） や 定数畳み込み（constant folding） が安全かつ効率的に行える。 
  • Stable Value API は、複雑な初期化ロジックを持つフィールドにも対応し、パフォーマンスと一貫性を両立させる。 

C1/C2 コンパイラとの相互運用とヒープバッファリング 

  • C1（インタプリタ寄りの最適化）と C2（最適化コンパイラ）でのコード混在時、フラット化された値と参照の両方を保持する必要がある。 
  • Stable Value API は、こうした混在環境でも効率的なヒープ使用とパフォーマンスを実現。 

Stable valueのグルーピングとコレクション 

  • Stable Value は、複数のフィールドが同時に初期化されるケースに対応。 
  • Stable List のような「遅延評価されるコレクション」も構築可能で、必要なときにだけ要素を初期化。 

トレードオフと今後の展望 

  • final は不変性を提供するが、パフォーマンス最適化には不十分な場合がある。 
  • Stable Value は、予測可能性・遅延性・パフォーマンス のバランスを取る手段として有効。 
  • 今後は、Project Loom との統合や、stable valueに対するコピー・変換最適化の可能性も検討。 

今後の計画 

  •  Stable Value API を Project Loom と組み合わせる可能性を探る 
  •  Stable valueに対する効率的なコピー／変換最適化の検討 
  •  Stable valueの初期化状態のオーバーヘッドと他手法との比較分析 

Auto-Vectorization in HotSpot (Emmanuel Peter)

Emmanuel（Compiler Team所属）がHotSpotの最適化コンパイラに実装された Superwordアルゴリズム を中心に、自動ベクトル化の仕組みと課題について解説した。ベクトル化による SIMD並列処理 の利点や、Javaにおける3つのベクトル化モデル（explicit・automatic・instrincic）についても触れている。 

技術的ポイント 

1. ベクトル化モデルの比較 

  • 明示的ベクトル化 (Explicit vectorization)：Vector APIやアセンブリ命令を使用。確実にベクトル化されるが、開発者の負担が大きい。 
  • 自動ベクトル化 (Automatic vectorization)：パターンマッチングに依存。脆弱で効果が限定的な場合もある。 
  • イントリンシックベクトル化 (Intrinsic vectorization)：特定メソッドに対するアセンブリスニペットの管理が必要で、保守が困難。 

2. Superwordアルゴリズムの仕組み 

  • 等形文（isomorphic statements） を検出し、ループを展開して命令列を再構成。 
  • ループを3つに分割：整列用のプレループ、高速処理用のメインループ、後処理用のポストループ。 
  • 依存グラフ を構築し、ロード・ストア命令から順にパッキング。 

3. デモとパフォーマンス 

  • 通常のマッピング処理において 5倍の高速化 を達成。 
  • 3D構造の法線ベクトルを扱い、光と影の再構成を並列処理。 

課題と改善点 

リダクション処理 

  • 和 (sum) やドット積 (dot products) などのリダクションはベクトル化が困難。 
  • ループ外への移動や再帰的フォールディングによる改善が提案された。 

ポインタとエイリアシング 

  • ポインタの重複や隣接による影響を解析。 
  • ランタイムチェック による推測コンパイルとマルチバージョニングの必要性。 

メモリアラインメント 

  • アラインメントが性能に大きく影響。 
  • 外部メモリ割り当てによる整列戦略が紹介された。 

今後の計画 

  •  未知のエイリアシングに対するランタイムチェックの実装 
  •  リダクション処理の改善 
  •  ベクトル化の有効性を判断するコストモデルの検討 
  •  制御フローを扱うためのif-conversionの実装 
  •  他のJDKプロジェクトとの連携によるシナジーの活用 

コミュニティへの呼びかけ 

Emmanuelは、パフォーマンス問題の報告と優先順位付けにおいて、コミュニティの積極的な関与を呼びかけた。 

Beyond the Vector API (Ivanov)

Ivanovは、Vector APIの目的として「データ並列処理」「移植性」「性能向上」を挙げ、2015年以降の3つの進化フェーズ（mesh inclines、Valhalla、intrinsic GDM）を紹介した。APIはJDK 16以後、JDK 25まで10回連続でincubatorとしてJEP化され、コミュニティによる採用も進んでいる。 

現状の課題 

  • APIの複雑さ 
  • 性能のばらつき 
  • ハードウェアへの直接アクセスの必要性 

ハードウェア固有APIの思考実験 

Ivanovは、低レベルでプラットフォーム固有の命令にアクセスできる「ハードウェア固有API」の構想を提案。これにより、性能向上とAPIの簡素化が期待される。 

実装と最適化の提案 

今後の計画 

  •  Intelのヘッダーファイル記述を活用し、VM用のアセンブラ実装を自動生成する方法を検討 
  •  Project Panamaのプリミティブとツールを活用し、ユーザーが必要な命令のみをインポートできる仕組みを検討（大規模APIの標準化を避ける） 

実装上の課題 

  • 数千の命令を扱うための手作業の負担 
  • コード品質と予測可能な性能の維持 
  • 命令サポートのランタイムAPIによる照会の必要性 

コミュニティと今後の方向性 

Ivanovは、ユーザー主導の改善と最適化の重要性を強調。大規模で静的なAPIの仕様化を避け、必要な命令だけを柔軟に取り込める設計を目指す。 

Better Immutability in Kotlin (Akhin)

1. Kotlinのインライン値クラスの課題 

  • Kotlinのinline value classはゼロコストのラッパーとして設計されているが、JVMの制約により最適化が失敗することがある。 
  • Javaとの相互運用性に問題があり、メソッド名のマングリングによりJavaコードからアクセスできないケースがある。 
  • 複数フィールドを持つvalue classへのニーズが高いが、実装の複雑さが障壁となっている。 

2. Project Valhallaによる改善 

  • ValhallaはJVMにおけるvalue classのネイティブサポートを提供し、識別子なしの型やランタイム最適化を可能にする。 
  • Kotlinのinline value classはValhallaのvalue classと設計思想が近く、Valhallaの導入により多くの課題が解消される。 
  • 複数フィールドのvalue classが可能になり、JVMによる最適化が自動で行われるようになる。 

3. Kotlinにおける初期化の課題 

  • Kotlinでは初期化が遅延（late construction）で行われるが、Valhallaでは早期初期化（early construction）が求められる。 
  • Kotlinの構文やプロパティアクセスの仕組みがValhallaと一致せず、言語仕様の変更が必要。 
  • 初期化フェーズの明示や新しい構文の導入などが検討されているが、後方互換性の問題が残る。 

4. 不変データの更新を簡素化する新機能 

  • Kotlinは新しいプロパティ「copy var」の導入を予定しており、代入時に自動でオブジェクトを再生成する。 
  • copy varはgetterとwitherの組み合わせとしてコンパイルされ、Javaとの互換性やバイナリ互換性が向上。 
  • copy関数やcopy-withラムダにより、ネストされた不変データの更新がより簡潔に記述可能になる。 

5. ラムダとの相互作用と今後の展望 

  • copy varとラムダの相互作用には課題があり、copy-awareなラムダやcopy-with関数の導入が検討されている。 
  • JITによる最適化や、copy varの明示による参照型との混同回避など、今後の改善点が議論されている。 
  • KotlinはValhallaの基盤の上に、より強力で使いやすい不変性モデルを構築しようとしている。 

今後の計画 

  •  Kotlinにおける早期初期化の問題をValhallaの値クラスと整合させる方法を検討する。 
  •  copyプロパティやcopy関数を活用し、不変データの更新をより使いやすくする方法を探る。 
  •  Kotlinの新しい不変性機能が既存の言語構成（ラムダなど）とどう相互作用するかを分析する。 
  •  ラムダ関数がcopy varレシーバーを扱えるように、多相性の表現方法を検討する。