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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

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

Ähnlich wie VMの歩む道。 Dalvik、ART、そしてJava VM (20)

Mehr von yy yank

Mehr von yy yank (11)

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