技術概要：JEDI – Java における宣言的および命令的クエリの評価

問題定義

Java 8 で導入された Java Stream API は、コレクションや無限データソースを処理するための宣言構文を提供し、従来の命令的なループベースのコードと比較して、開発者の生産性、コードの可読性、保守性の向上を目指しています。この API は高レベルの抽象化を通じて並列計算を簡素化しますが、既存の文献は、ストリームベースの実装が同等の命令的コードに比べて性能ペナルティに悩まされることが多いことを示しています。

この研究で特定された重要なギャップは、Stream API を対象とした専用ベンチマークスイートの欠如です。そのようなベンチマークがない場合、以下のことが困難になります：

1. 研究者およびライブラリ開発者： Java クラスライブラリ（JCL）内の Stream API 実装を最適化すること。
2. アプリケーション開発者： 効率的なコードを書くために、さまざまなストリーム操作と並列化戦略の性能特性を理解すること。

現在のベンチマークは、Stream API を明示的にターゲットとしていないか、複雑な現実世界のデータ処理ワークロードを反映していない単純な合成パイプラインに依存しています。

手法

このギャップに対処するため、著者らは、SQL クエリを Java ソースコードに変換して自動的に生成されたベンチマークスイートであるJEDI（Java Evaluation of Declarative and Imperative Queries）を提示します。

生成プロセス

1. ソース資料： 著者らは、結合、集約、フィルタリング、ソートなど、さまざまなデータ処理機能を含む複雑なクエリで構成される、広く使用されているデータ分析ベンチマークであるTPC-Hベンチマークを利用します。
2. コード変換： 著者らは既存のツールS2S（SQL to Stream）を拡張し、SQL クエリを複数の意味的に等価な Java 実装に変換しました。
   • スキーママッピング： SQL テーブルは、オブジェクトのメモリ内配列にマッピングされます。
   • クエリ変換：
     • SELECT 投影 $\rightarrow$ map(...)
     • WHERE 述語 $\rightarrow$ filter(...)
     • ORDER BY $\rightarrow$ sorted(...)
     • LIMIT $\rightarrow$ limit(...)
     • GROUP BY および集約 $\rightarrow$ 生成されたコレクタを伴う collect(...)
     • JOIN $\rightarrow$ 構築側のためにハッシュマップを構築する flatMap または mapMulti を介して実装されます。
3. 実装バリエーション： 単一の SQL クエリに対して、JEDI は異なるコーディングパターンと実行戦略を比較するために複数のバリエーションを生成します：
   • 逐次変種：
     • O1（フィルタ融合）： 複数の述語を単一の filter 呼び出しに結合することと、複数の連鎖呼び出しを比較します。
     • O2（結合実装）： 結合操作に対して mapMulti を使用することと flatMap を使用することを比較します。
   • 並列変種（O3）：
     • P： 順序付き並列ストリーム（parallel()）。
     • PU： 順序なし並列ストリーム（parallel().unordered()）。
     • CG： groupingByConcurrent を使用する順序なし並列ストリーム（ロックベースの同期を伴う共有状態）。
     • CGCC： スレッドセーフなダウンストリームコレクタを伴う CG（ロックフリーの原子操作）。
   • 命令的ベースライン： ストリームバージョンと同じデータ構造と操作順序を使用するループベースの実装で、「Stream API のオーバーヘッド」を測定します。

評価セットアップ

• ハードウェア： 2 つの異なるアーキテクチャ：Intel Xeon Gold（16 コア）および ARM Neoverse-N1（80 コア）。
• JVM： Oracle JDK 24 および GraalVM 24。
• データセット： 逐次分析用の TPC-H スケールファクター 1（1GB）および並列分析用のスケールファクター 10（10GB）。
• ツール： 定常状態の性能を確保するためのウォームアップと測定イテレーションを備えた Java Microbenchmark Harness（JMH）。

主な貢献

1. JEDI ベンチマークスイート： TPC-H から派生したオープンソースのベンチマークスイートの公開で、意味的に等価なストリームおよび命令的実装を自動的に生成します。
2. コードジェネレータ： 複数の実装戦略（逐次最適化およびさまざまな並列縮小パターン）をサポートする S2S の拡張バージョン。
3. 性能ガイドライン： 経験的データに基づいて、Stream API を効率的に使用するための導出されたベストプラクティスのセット。
4. オーバーヘッド分析： API 抽象化の性能コストを分離するために、同一のデータ構造と操作順序を使用したストリームベースのコードと命令的コードの直接比較。

結果と知見

RQ1：逐次最適化（フィルタ融合および結合実装）

• フィルタ融合（O1）： 述語を単一の filter 呼び出しに結合すると、特に多数の述語が存在する場合に性能が向上します（例：7 つの述語を持つマイクロベンチマークで 3.54 倍の高速化）。
• 結合実装（O2）： 結合に対して flatMap の代わりに mapMulti を使用すると、大幅な改善が得られます（Intel JDK での幾何平均の高速化は 1.38 倍）。
• 結論： 開発者は可能であれば O1 および O2 の両方を適用すべきです。

RQ2：並列化戦略

• 普遍的な勝者の不在： 単一の並列戦略がすべてのシナリオを支配するわけではありません。性能は、特に集約グループの数と集約の性質に大きく依存します。
• スカラー対グループ化集約：
  • スカラー集約（グループ化なし）または少数のグループの場合、共有状態戦略（CG、CGCC）よりも順序付き（P）または順序なし（PU）並列ストリームの方が、競合が低いため優れています。
  • 多数のグループを伴うグループ化集約の場合、CG（groupingByConcurrent を使用）が一般的に最良の戦略です。グループの数が増加すると、ロック競合が減少し、ロックベースの同期が効率的になります。
• ロックフリー対ロックベース： CGCC（ロックフリー）は CG（ロックベース）を常に上回るわけではなく、実装の複雑さを導入します。ただし、CG が高い競合に悩まされる非常に少数のグループの場合、CGCC はより堅牢です。
• Distinct 操作： 一般的に distinct には順序なしストリーム（PU）が推奨されますが、本研究では、少数の異なる要素を持つストリームの場合、順序なしストリームにおける共有 ConcurrentHashMap の管理のオーバーヘッドにより、順序付き並列ストリーム（P）が最大 2 倍高速であることが判明しました。

RQ3：ストリーム対命令的パフォーマンス

• 命令的優位性： 命令的なループベースのコードは、一貫してストリームベースのコードを上回ります。
• 規模： 異なる JVM およびアーキテクチャ全体で、最良の逐次ストリーム実装に対する命令的コードの幾何平均の高速化は1.28 倍から 1.41 倍の範囲です。
• 文脈： これは以前の知見を確認していますが、著者らはこのギャップが一部の先行研究よりも小さいことに注意し、時間の経過とともに Stream API 実装が改善されていることを示唆しています。ただし、パフォーマンスが重要なコードの場合、命令的コードは依然として大幅に高速です。

RQ4：コードの複雑さ

• 可読性： パフォーマンスのギャップにもかかわらず、ストリームベースのコードは著しく低い複雑さメトリックを示します。
• メトリック： ベースラインのストリームコードの認知的複雑さは、命令的コードよりも2.43 倍低いです。最適化（O1+O2）を行っても、ストリームコードは命令的コードよりも1.62 倍低い複雑さのままです。
• トレードオフ： ストリームコードを最適化すること（例：フィルタの融合）は、その複雑さメトリックを増加させますが、命令的同等物の複雑さより低い状態に保ちます。

意義と主張

この論文は、JEDI を Java コミュニティおよび JVM 実装者にとって不可欠なツールとして位置づけています：

• 開発者にとって： ワークロードの特性に基づいて（例：大規模なグループの場合は groupingByConcurrent）、特定のパターン（例：mapMulti）を提案し、Stream API の性能オーバーヘッドを最小化するためのデータ駆動型のガイドラインを提供します。
• ライブラリ実装者にとって： ベンチマークスイートと特定された「オーバーヘッド」は、命令的コードとの性能ギャップを埋めるために Stream API 実装を最適化するための基準を提供します。
• 研究者にとって： 将来の最適化、リファクタリングツール、または並列化戦略を評価するための、再現可能で複雑なワークロード（TPC-H 派生）を提供します。

著者らは、JEDI が現在、配列ベースのデータソースおよび特定の SQL-to-Stream 変換パターンに焦点を当てているという制限を謙虚に認め、将来の作業ではジェネレータを拡張してより多くの Stream API メソッドをカバーし、データソース（例：リスト、セット）を変化させることを計画しています。