まだまだ進化するJVM！（J Lang Fest Kansai Online #1 講演資料）

© 2020 NTT DATA Corporation
まだまだ進化するJVM！
2020年10月4日 J Lang Fest Kansai Online #1
株式会社NTTデータ技術開発本部
阪田浩一

© 2020 NTT DATA Corporation 2
自己紹介
• 阪田浩一（さかた -）
• 通称じゅくちょー
• JVMになりたい人
• NTTデータでJava/OpenJDK + GraalVM
の研究開発とそのサポート業に従事しています
• Javaチャンピオン
• OpenJDK Author
jyukutyo

JVMは
25年間にわたり
進化してきた

これまでのJVMの進化
• Javaは遅い、おもちゃだ（という初期の評価）
• 大きな機能にも多くの変更があった
• JITコンパイル
• そもそも最初はJITコンパイルがなかった
• -client/-server から階層型コンパイルへ
• GCアルゴリズム
• CMSに至っては1.4で追加され、14で削除された
• 最近でもShenandoah、ZGCを追加した
• バイトコード命令の数は1つしか増えていない
• invokedynamic

Javaの研究ロードマップ
Java 15
リリース
現在近い未来
• Project Valhalla
• Inline Typesで
バイトコードも追加
• Project Loom
• 仮想スレッドを追加
• Project Panama
• JVMとネイティブコード
の相互運用改善
さらに未来
？？？

JVMを
再実装する！
（ランタイムの重要な部分中心）

それが
Project Metropolis
OpenJDK: Metropolis https://openjdk.java.net/projects/metropolis/

再実装とは？
C++の既存実装
↓
Javaで再実装

Java on Java

Javaで再実装するメリット
1. JVM自体の最適化をより詳細にコントロールできる
2. 他言語を使わない、Javaのみであることで
他言語自体の変更の影響を受けずに済む
• C++自体も新バージョンが当然出る
3. OpenJDK開発者の労力削減と門戸を広げられる
• スキルとしてJavaとC++の両方が必要だった
4. 新ハードウェア対応や新バイトコード導入といった機能追加の
速度を向上できる
Call for Discussion: New Project: Metropolis https://cr.openjdk.java.net/~jrose/metropolis/Metropolis-Proposal.html

リスクが大きい？
• 前提：インキュベーションプロジェクトである
1. Javaとなることで、JVM起動のパフォーマンスが悪くなるリスク
2. そのJavaコードへのGCやJITコンパイルの動作が、
アプリケーションの実行に影響するリスク
3. 現在のJavaにはC++にある高密度のデータ構造が
ないことによるパフォーマンスのリスク
• 例：配列のメモリレイアウト
4. 実装を変更することで品質とパフォーマンスの低下リスク
Call for Discussion: New Project: Metropolis https://cr.openjdk.java.net/~jrose/metropolis/Metropolis-Proposal.html

とはいえすでに
Java on Javaで
作られた部分があります

どの部分だと
思いますか？？

答え：
JITコンパイラ

GraalVMの
JITコンパイラ

HotSpotで動作する
Java実装のJITコンパイラを
作ったことが
Graal(VM)のスタート

GraalVMとHotSpot VM
• GraalVMはHotSpot VMがベース
HotSpot VM
Compiler Interface
C2C1
HotSpot VM
C++
GraalVM
Compiler
Interface
GraalC1
HotSpot VM
JVMCI
Java

GraalVMとの関係性
• GraalVM
• Oracle Labsが開発した
Java製JITコンパイラがベース
• GraalVM JITコンパイラ（graal）
• OpenJDKにもそのJITコンパイラがポートされている
• JEP 317: Experimental Java-Based JIT Compiler
• -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler
で実際にC2コンパイラと入れ替えて使えます
みんなのJava OpenJDKから始まる大変革期！ https://gihyo.jp/book/2020/978-4-297-11199-1

GraalVMとの関係性
• GraalVMのネイティブイメージ生成機能
• クラスファイルから実行ファイルを生成し、
JVMを利用せずにアプリケーションを実行可能とする

GraalVMのネイティブイメージ機能
• AOT（Ahead-of-Time：事前）コンパイル
「実行前」に
機械語へコンパイル！

JITコンパイル
「実行中」に
JVM

超簡略化して考えると…
❌
「実行中」に
「実行前」に

同じようなことを
やっているように
見えませんか？

（追加スライド）
2つのコンパイラの処理は
重なる部分があったため、
このJITコンパイラを元にして
ネイティブイメージ生成機能を
作ることができた

JITコンパイラが
Javaで書かれていると

JITコンパイラの
Javaコードも
JITコンパイルする
必要がある

つまり
アプリケーション起動時に
その分の時間がかかる

JITコンパイラの
コードをAOTコンパイル
（ネイティブコンパイル）
してしまえば
ある程度解決できる

JITコンパイラコードのコンパイル
JavaでJITコンパイラを書く
↓
そうなるとJITコンパイラのJavaコードを
JITコンパイルすることが必要
↓
あらかじめJITコンパイラのJavaコードを
ネイティブコンパイルしておく
（libgraal/libjvmcicompiler）

次にJavaに置き換える
ものも同じようにする

JVMとGraalVMは
互いに影響を
及ぼし合っている

ネイティブコンパイルを採用するトレードオフ
• 事前にコンパイルしたものを使うので、
利用できない機能が出てくる
• コードのinstrumentation
• 動的な再最適化
• 性能のトレードオフ
https://twitter.com/thomaswue/status/1145603781108928513

Project Metropolisの現在
• 現在：Java 15ベースのEAビルドがある
• https://jdk.java.net/metropolis/
• GraalVM JITコンパイラがデフォルトコンパイラ
• ネイティブコンパイル済み
• 次にどのコンポーネントがJava on Javaとなるのかは明らかでない
• たとえばGCは難しいだろうと言われている

今後想定される前提作業
• Java on Javaするにはその機能のコンポーネントの
JVM内でインタフェースを定義、整備する
• 例：JITコンパイラの場合
• JEP 243: Java-Level JVM Compiler Interface

まとめ
• Project Metropolis
• Java on JavaでJVMを再実装していく！
• GraalVM JITコンパイラを足がかりにしていく！

まだまだ進化するJVM！（J Lang Fest Kansai Online #1 講演資料）

Recommended

Recommended

More Related Content

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

まだまだ進化するJVM！（J Lang Fest Kansai Online #1 講演資料）