VMの歩む道。 Dalvik、ART、そしてJava VM

VMの歩む道。
Dalvik、ART、そしてJava VM
JJUG CCC 2017 Spring
#ccc_a7 #jjug_ccc
@yy_yank

#ccc_a7 #jjug_ccc
でつぶやいてください
ハッシュタグ

自己紹介
やんく(@yy_yank)
　　　　　　　こいつです
　　　　　　　・JJUG CCC登壇3回目
　　　　　　　・vi好き
　　　　　　　・でもサクラエディタicon
　　　　　　　・JavaとKotlinが好き

JVM初心者ですか？
僕より詳しくないですか？
Question1

Android開発したこと
がありますか？
Question2

サーバーサイドを
Javaで開発したことが
ありますか？
Question3

・VMにﾁｮｯﾄｸﾜｼｸﾅﾙ(not エキスパート)
・VMの比較対象を増やす
・知らずに批評をしない、知ってる知識を
ベースにフェアになる
本セッションのゴール

・Oracle vs Google
・Apache Harmonyの細かい話
過去のJJUGナイトセミナーのこの内容を読
むと良いと思います。
http://www.publickey1.jp/blog/16/googl
eoraclejava_apiitjjug.html
本セッションで話題にしないこと

・実践的なVMのパフォーマンスチューニング
Javaパフォーマンスという
本があるので
それを読んでいただければ
おそらく・・・！
本セッションで話題にしないこと

アジェンダ
1. Javaの人にとってのDalvik/ART
2.Androidの人にとってのJVM(not Dalvik/ART)
3.こんなに違う、マシン命令
4.バイナリ(class、dex)
5.ランタイムごとのAOT、JIT、GC
6.まとめ

アジェンダ
▷ 1. Javaの人にとってのDalvik/ART
6.まとめ

・別に知らなくていい（身も蓋もない）
・知ってた方がプラットフォームを意識した設
計・プログラミングが出来るのでは
・HotSpot以外のVMを知ってた方が翻って
HotSpotの理解につながるのでは

☆今更ながら前提
・現状Oracleの提供するJVM = HotSpot
・AndroidのVM = ART(昔はDalvik)
・それぞれダルビック、アートと読む
ARTはDalvikがベースとなっている

Q.HotSpot VM以外無いの？
A.あります
・HotSpotは(元Sun、現Oracle所有)
・IBM J9 VM(IBM)
・JRockit(元BEA、現Oracle所有)
など

Q.HotSpot VM以外無いの？
A.あります
・HotSpotは(元Sun、現Oracle所有)
・IBM J9 VM(IBM)
・JRockit(元BEA、現Oracle所有)
など
とても大胆に分けてしまうと、大体
の人はHotSpotを使っていて、
JVMの処理系を意識していない
ものと思います

◯JRockit・・・1.6までしかない。1.7で
HotSpotと統合されたようです
◯J9 VM・・・Websphere、DB2などで利用
されてきました。Open J9というプロジェクト
もありアクティブですが、シェアはHotSpot
が多いと思われます

◯JRockit・・・1.6までしかない。1.7で
HotSpotと統合されたようです
◯J9 VM・・・Websphere、DB2などで利用
されてきました。Open J9というプロジェクト
もありアクティブですが、シェアはHotSpot
が多いと思われます
ということで、本セッションでは
HotSpot、Dalvik/ARTを中心に話
をします

cf. J9 VMの情報は以下が詳しい
IBM SDK for Java 8の全貌
https://www.slideshare.net/takakiyo/jj
ugccc-201ibm-sdk-for-java-8

アジェンダ
▷2.Androidの人にとってのJVM(not Dalvik/ART)
6.まとめ

・JavaもどきとかAndroid Javaとはなぜ言う人
がいるか（またそれに対しての対応）
・違いを知る。実機では動かないけどIDEでは
動く、なぜ？とか
・なぜHotSpotがあるのにAndroidはVMを独
自に用意した？
2.Androidの人にとってのJVM

・言葉が悪い
・JavaであってちょっとJavaでなくてちょっと
JavaなのがAndroid
・Android Javaぐらいが妥当な表現か
Javaもどき問題

Javaもどき問題
・JLSは満たしているようだが、
JVMSは満たしていない
(歴史的経緯でTCKをパスしていない)
・標準ライブラリが違う
例えばjava.beansパッケージに含まれているク
ラスが少ないなど

アジェンダ
▷ 3.こんなに違う、マシン命令
6.まとめ

・HotSpotはスタックマシン
・Dalvik/ARTは(特殊な)レジスタマシン
スタックマシンは命令を積み上げ
レジスタマシンは命令をレジスタへの登録
Dalvik/ARTの場合はメモリ領域をレジスタと呼ん
でいる（特殊とはそのあたりのこと）

・HotSpotはスタックマシン
・Dalvik/ARTは(特殊な)レジスタマシン
スタックマシンは命令を積み上げ
レジスタマシンは命令をレジスタへの登録
Dalvik/ARTの場合はメモリ領域をレジスタと呼ん
でいる（特殊とはそのあたりのこと）
そもそもマシンの
モデルが違った

簡略例:スタックマシン
メモリ
ス
タ
ッ
ク

メモリ
１ス
タ
ッ
ク
１をPUSH

メモリ
２
１
ス
タ
ッ
ク
2をPUSH

メモリ
1ス
タ
ッ
ク
2をPOP

メモリ
ス
タ
ッ
ク
1をPOP

メモリ
3ス
タ
ッ
ク
POPした1 と 2
を加算して
PUSH

簡略例:レジスタマシン
メモリ
レ
ジ
ス
タ
R0
R1
R2
R3

メモリ
1レ
ジ
ス
タ
R0
R1
R2
R3
R0に1を登録

メモリ
1
2
レ
ジ
ス
タ
R0
R1
R2
R3
R1に2を登録

メモリ
1
2
3(R0 + R1)
レ
ジ
ス
タ
R0
R1
R2
R3
R2にR0+R1を
登録

簡略例:Dalvik/ARTのレジスタマシン
メモリ
メソッドB
メソッドB
メソッドA
メソッドA
レ
ジ
ス
タ
R1
R0
R1
R0

メモリ
メソッドB
メソッドB
メソッドA
メソッドA
レ
ジ
ス
タ
R1
R0
R1
R0
メソッドごとにスタック。
でもレジスタマシン。

メモリ
メソッドB
メソッドB
メソッドA
メソッドA
レ
ジ
ス
タ
R1
R0
R1
R0
レジスタと言いつつ
演算用のメモリ領域に確保し
ている

メモリ
メソッドB
メソッドB
メソッドA
メソッドA
レ
ジ
ス
タ
R1
R0
R1
R0
むずかしい！？

このスライドが詳しいです。
Dalvik仮想マシンのアーキテクチャ改訂版
https://www.slideshare.net/kmt-t/dalvi
k-10316622
というかTakuya Matsunagaという方がすごい

なんで違う？
HotSpotはスタックマシン
・ハードウェアを問わず動かしやすいアーキ
テクチャ
・Run Anywhere的なところを優先した結果
なのか・・・？

☆なんで違う？
Dalvik/ARTは（特殊な）レジスタマシン
・instruction dispatchを避けたかった
・不要なメモリアクセスを避けたかった
・命令処理の流れを素早くさばきたい

☆なんで違う？
Dalvik/ARTは（特殊な）レジスタマシン
・instruction dispatchを避けたかった
・不要なメモリアクセスを避けたかった
・命令処理の流れを素早くさばきたい
・instruction dispatchとは
メモリからの命令のフェッチ
や読み込み、ジャンプなどな
ど

やっと
マシン命令の話

・HotSpot
マシン命令の一例
invokevirtual = インスタンスのメソッド呼び出し
invokeinterface = interfaceのメソッド呼び出し
invokestatic = staticメソッドの呼び出し
invokespecial = コンストラクタの呼び出し
よく見るやつですね

・Dalvik/ART
invoke-virtual = インスタンスのメソッド呼び出し
invoke-interface = interfaceのメソッド呼び出し
invoke-static = staticメソッドの呼び出し
new-instance = インスタンスの生成

いえいえ、違うところ
も…

・HotSpot
invokevirtual = 0xb6
invokeinterface = 0xb7
invokestatic =0xb8
invokespecial = 0xb9

・Dalvik/ART
invoke-virtual = 0x6e
invoke-interface = 0x72
invoke-static = 0x71
new-instance = 0x22

・Dalvik/ART
invoke-virtual = 0x6e
invoke-interface = 0x72
invoke-static = 0x71
new-instance = 0x22
オペコードの値は違う(そりゃそうか)

・Dalvik/ARTとHotSpotでどちらにもあるもの
return系命令
const系命令
if系命令
などなど。

return系命令
const系命令
if系命令
などなど。
3.こんなに違う、マシン命令HotSpot:
ireturn(0xac)
lreturn(0xad)
freturn(0xae)
Dalvik/ART:
return-void(0x0e)
return (0x0f)
return-wide(0x10)
return-object(0x11)

return系命令
const系命令
if系命令
などなど。
3.こんなに違う、マシン命令HotSpot:
iconst_ほげほげ
lconst_ほげほげ
dconst_ほげほげ
Dalvik/ART:
const/4
const/16
const

return系命令
const系命令
if系命令
などなど。
などなど・・・。
（気になる人は命令セッ
トを比較してみて下さい）

return系命令
const系命令
if系命令
などなど。
命令の名称やオペコードの
値は色々違っているのだけ
ど、大体やる処理としては
同じ

・Dalvik/ARTにしかなさそうなもの
move命令
->レジスタペアを別のレジスタに移動
invoke-polymophicとinvoke-custom
->Androidの8.0から新しく使えるようになるオペコード。
MethodHandleを呼び出すのだとか・・！

・こんなに違う、は主にVMのマシンアーキテクチャだった
・それにともなって、マシン命令も違う（というより、オペ
コードの値は違う）
・実行バイナリが違うことも１つ大きな要因だと思います
(この後に紹介します)

アジェンダ
2.Androidの人にとってのJVM(not dalvik/ART)
▷ 4.バイナリ(class、dex)
6.まとめ

・HotSpotはclassファイル
・Dalvik/ARTはdex(Dalvik Executable)ファイル
がそれぞれVMにロードされて
マシンコードになって実行される

ソースコード
(javaファイル)
dexツール dexファイル
HotSpot VM Dalvik/ART VM
classファイル

☆classファイルフォーマット
1.magic;
2.minor_version;
3.major_version;
4.constant_pool_count;
5.cp_info
constant_pool[constant_pool_count-1];

1.magic;
2.minor_version;
3.major_version;
5.cp_info
いわゆるひとつ
のCAFEBABE
.classに必ずある
もの

1.magic;
2.minor_version;
3.major_version;
5.cp_info
クラスファイルの
version

1.magic;
2.minor_version;
3.major_version;
5.cp_info
定数プール
のカウント

1.magic;
2.minor_version;
3.major_version;
5.cp_info
定数プール

7.access_flags;
8.this_class;
9.super_class;
10.interfaces_count;
11.interfaces[interfaces_count];
12.fields_count;
13.field_info fields[fields_count];
クラスやフィールドへ
のアクセスフラグ。
publicとかprivateとか
アレ

7.access_flags;
8.this_class;
9.super_class;
12.fields_count;
このクラス自身と
継承しているスーパー
クラスの情報

7.access_flags;
8.this_class;
9.super_class;
12.fields_count;
interfaceのカウントと
intefefaceの配列

7.access_flags;
8.this_class;
9.super_class;
12.fields_count;
フィールドのカウントと
フィールドの配列

14.methods_count;
15.method_info methods[methods_count];
16.attributes_count;
17.attribute_info attributes[attributes_count];

14.methods_count;
メソッドのカウントと
メソッドの配列

14.methods_count;
attributeという特殊な
もののカウントと
その配列

・versioningされている
・情報ごとにカウントを持っている
・各情報の配列を持つ
・アクセシビリティの情報も持つ
・ただしバイナリを直接読むのは辛いし
javapで良い気がする

☆dexファイルフォーマット
1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs

1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
ヘッダー情報

1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
文字列定数のID

1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
型情報のID

1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
メソッドの
プロトタイプ情報のID
(DEXでのテンプレート)

1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
フィールド情報のID

1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
メソッド情報のID

1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
クラス定義リスト

8.call_site_ids
9.method_handles
10.data
11.link_data

8.call_site_ids
9.method_handles
10.data
11.link_data
全てcall siteの
参照情報
(call siteはメソッドの場
所的なもの)

8.call_site_ids
9.method_handles
10.data
11.link_data
ハンドリングするメソッド
のリスト

8.call_site_ids
9.method_handles
10.data
11.link_data
全部のデータテーブルを
持つ

8.call_site_ids
9.method_handles
10.data
11.link_data
静的リンクされた情報

・基本的に持っている情報は同じ
(身も蓋もない)
・ただ並び順も持ち方も違う
・もちろんそれぞれのバイトコードは
それぞれのVMでしか動かない

アジェンダ
▷ 5.ランタイムごとのAOT、JIT、GC
6.まとめ

・JIT(Just-In-Time Compiler)とは
実行時にネイティブコードにコンパイルする
・AOT(Ahead-Of-Time Compiler)とは
実行前にネイティブコードにコンパイルする
・GCとは
ガベージコレクション。JavaもAndroidも共通のメモリ管
理の機構

・JIT(Just-In-Time Compiler)とは
実行時にネイティブコードにコンパイルする
・AOT(Ahead-Of-Timeコンパイラ)とは
実行前にネイティブコードにコンパイルする
・GCとは
ガベージコレクション。JavaもAndroidも共通のメモリ管
理の機構
本来、AOT、JITとGCを並べるのは
変な感じですが、
資料の構成上並べて紹介する形とします

・HotSpotでJITが動いてるかどうか
->だいたい動いてる
・ホットなスポットだけJITする
・起動時にvm optionに -XX:+PrintCompilation って付
けるとめっちゃJITされたログが出てくる
・-Djava.compiler=none を付け加えるとJITが無効に
なって何もログが出なくなる

☆JITの場合(HotSpot)
ぼく「javac Hello.java」
ぼく「java Hello」
HotSpot「メソッド実行前にチェックします」
HotSpot「これはネイティブコードにしときますね〜」

☆JITの場合(Dalvik)
ぼく「アプリインストールした。」
ぼく「起動してみよう」
Dalvik「メソッド実行前にチェックします」
Dalvik「これはネイティブコードにしときますね〜」

☆AOTの場合(ART)
ぼく「アプリインストールしよっと」
ART「あ、これインストール中でもネイティブコードに出来
ますわー」
ART「ネイティブコードにしときますね〜」
ぼく「よし、インストール出来た。使ってみよ」

☆AOTの場合(ART)
ますわー」
ART「ネイティブコードにしときますね〜」
ぼく「よし、インストール出来た。使ってみよ」
実行時のオーバーヘッドが少ない！！！

Google
IO 2014
the ART
Runtime
より

ココ！！！
Google
IO 2014
the ART
Runtime
より

☆JIT or AOTについて
・HotSpotはJIT/Interpreterを採用
・Dalvik(Android 5.0以前)まではJIT/Interpreter
・ART以降(Android 5.0)はAOTを利用している

・Dalvik(Android 5.0以前)まではJIT
Android 5.0は
2014年から

5.ランタイムごとのAOT、JIT、GCAOT
JIT
Interpreter
を選べる

Android 7.0からはAOT + JITという形に
5.ランタイムごとのAOT、JIT、GCAOT
JIT
Interpreter
を選べる

☆Android 5.0のART
ますわー」
ぼく「インストールめっちゃ長い。電池消費やばい。もうマ
ヂムリ」
(ということもあったらしい)

Google IO 2016
The Evolution of
ARTより

☆Android 7.0のAOT + JIT
ますわー。でも電池消費するからちょっとだけ。あとは
JITさんに任せますわ」
ぼく「よしインストール出来たし、アプリ使ってみよっと」

☆Android 7.0のAOT + JIT
ますわー。でも電池消費するからちょっとだけ。あとは
JITさんに任せますわ」
ぼく「よしインストール出来たし、アプリ使ってみよっと」->
ユーザーのストレスが少ない形に

DalvikとARTの違いはこのあたり
・そもそもDalvikはシングルコア向けに作られていた
・Androidは8コアになった。だからART
・スイープのpauseがARTの方が短くなったらしい
・dexファイルが動く、など基本的なところは同じ
・違いはAOTが入ったこと、GC改善、ロギング改善など

???「なるほど。
AOTいいんじゃない？」

???「HotSpotでやれば
良いじゃないか」

☆HotSpotのAOT
・・・・・・・・・・・・・。

☆HotSpotのAOT
あると思います！！！！

☆JEP295
・Java 9では入らない
・javaコマンドオプションでAOTライブラリを指定
・It uses Graal as the code-generating backend.

☆Graalとは
・Next generation compilation technology
supporting Java, Ruby, R, JavaScript, LLVM, and
more...
というJavaで書かれてるヤバいやつ

99%Javaです！

☆GCについて
HotSpotだと
・シリアル GC
・パラレル GC
・CMS GC(Java 9でdeprecated?)
・G1GC(Java 9でデフォルト?)
ココから選ぶことになる

☆ARTだと
dalvik.vm.gctypeプロパティを変更するか、-Xgcオプショ
ンで
・CMS GC(デフォルト)
・Semi Space GC(いわゆるコピーGC)
・Generational Semi Space GC(いわゆるコピーGC)

☆ARTだと
ンで
可動オブジェクトを動かす空間
と非可動オブジェクトの空間を
持つ。
移動させてシュッとGC

☆ARTだと
ンで
こっちはそれを世代別に

5.ランタイムごとのAOT、JIT、GCDalvik
Google IO 2014 the ART
Runtimeより

5.ランタイムごとのAOT、JIT、GCART
Google IO 2014 the ART
Runtimeより

アジェンダ
▷ 6.まとめ

なんのためのDalvik、ARTか
・Androidに最適化されている
・ARTは最近？のAndroid端末に合わせての更なる最適
化
・当たり前だがプラットフォームが違えば要求される実行
環境(VM)も違う
・プラットフォームを優先した結果独自VMとして別々の道
を歩むことになった
6.まとめ

・プラットフォームに合わせるために犠牲はつきもの？
->Android SDKに無くて、JDKにあるものはあるが、バラ
ンスを考えてそうなっている
・どちらも頑張った結果
->HotSpotはPCマシン(あるいはサーバー)前提で最適化
を頑張った結果、Dalvik/ARTはAndroidプラットフォーム
前提で頑張った結果
6.まとめ

・VMをブラックボックスとして扱う技術者にならないように
(自戒を込めて)
・どう動いているのか意識して、その上でIDEに任せて楽
をしたい
・何が起こってるか理解できないと問題を解決できない
6.まとめ

VMの歩む道。 Dalvik、ART、そしてJava VM

More Related Content

What's hot (20)

Viewers also liked (20)

More from yy yank (12)

VMの歩む道。 Dalvik、ART、そしてJava VM