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

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

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

4.
質問です！！

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

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

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

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

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

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

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

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

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

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

15.
Q.HotSpot VM以外無いの？
A.あります
・HotSpotは(元Sun、現Oracle所有)
・IBM J9 VM(IBM)
・JRockit(元BEA、現Oracle所有)
など
1. Javaの人にとってのDalvik/ART

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

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

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

19.
1. Javaの人にとってのDalvik/ART
cf. J9 VMの情報は以下が詳しい
IBM SDK for Java 8の全貌
https://www.slideshare.net/takakiyo/jj
ugccc-201ibm-sdk-for-java-8

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

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

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

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

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

25.
ちょっとその前に

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

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

28.
簡略例:スタックマシン
3.こんなに違う、マシン命令
メモリ
ス
タ
ッ
ク

29.
簡略例:スタックマシン
3.こんなに違う、マシン命令
メモリ
１ス
タ
ッ
ク
１をPUSH

30.
簡略例:スタックマシン
3.こんなに違う、マシン命令
メモリ
２
１
ス
タ
ッ
ク
2をPUSH

31.
簡略例:スタックマシン
3.こんなに違う、マシン命令
メモリ
1ス
タ
ッ
ク
2をPOP

32.
簡略例:スタックマシン
3.こんなに違う、マシン命令
メモリ
ス
タ
ッ
ク
1をPOP

33.
簡略例:スタックマシン
3.こんなに違う、マシン命令
メモリ
3ス
タ
ッ
ク
POPした1 と 2
を加算して
PUSH

34.
簡略例:レジスタマシン
3.こんなに違う、マシン命令
メモリ
レ
ジ
ス
タ
R0
R1
R2
R3

35.
簡略例:レジスタマシン
3.こんなに違う、マシン命令
メモリ
1レ
ジ
ス
タ
R0
R1
R2
R3
R0に1を登録

36.
簡略例:レジスタマシン
3.こんなに違う、マシン命令
メモリ
1
2
レ
ジ
ス
タ
R0
R1
R2
R3
R1に2を登録

37.
簡略例:レジスタマシン
3.こんなに違う、マシン命令
メモリ
1
2
3(R0 + R1)
レ
ジ
ス
タ
R0
R1
R2
R3
R2にR0+R1を
登録

38.
簡略例:Dalvik/ARTのレジスタマシン
3.こんなに違う、マシン命令
メモリ
メソッドB
メソッドB
メソッドA
メソッドA
レ
ジ
ス
タ
R1
R0
R1
R0

39.
簡略例:Dalvik/ARTのレジスタマシン
3.こんなに違う、マシン命令
メモリ
メソッドB
メソッドB
メソッドA
メソッドA
レ
ジ
ス
タ
R1
R0
R1
R0
メソッドごとにスタック。
でもレジスタマシン。

40.
簡略例:Dalvik/ARTのレジスタマシン
3.こんなに違う、マシン命令
メモリ
メソッドB
メソッドB
メソッドA
メソッドA
レ
ジ
ス
タ
R1
R0
R1
R0
レジスタと言いつつ
演算用のメモリ領域に確保し
ている

41.
簡略例:Dalvik/ARTのレジスタマシン
3.こんなに違う、マシン命令
メモリ
メソッドB
メソッドB
メソッドA
メソッドA
レ
ジ
ス
タ
R1
R0
R1
R0
むずかしい！？

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

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

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

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

46.
やっと
マシン命令の話

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

48.
・Dalvik/ART
マシン命令の一例
invoke-virtual = インスタンスのメソッド呼び出し
invoke-interface = interfaceのメソッド呼び出し
invoke-static = staticメソッドの呼び出し
new-instance = インスタンスの生成
3.こんなに違う、マシン命令

49.
大体一緒やん

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

51.
3.こんなに違う、マシン命令
・HotSpot
マシン命令の一例
invokevirtual = 0xb6
invokeinterface = 0xb7
invokestatic =0xb8
invokespecial = 0xb9

52.
・Dalvik/ART
マシン命令の一例
invoke-virtual = 0x6e
invoke-interface = 0x72
invoke-static = 0x71
new-instance = 0x22
3.こんなに違う、マシン命令

53.
・Dalvik/ART
マシン命令の一例
invoke-virtual = 0x6e
invoke-interface = 0x72
invoke-static = 0x71
new-instance = 0x22
オペコードの値は違う(そりゃそうか)
3.こんなに違う、マシン命令

54.
・Dalvik/ARTとHotSpotでどちらにもあるもの
return系命令
const系命令
if系命令
などなど。
3.こんなに違う、マシン命令

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

56.
・Dalvik/ARTとHotSpotでどちらにもあるもの
return系命令
const系命令
if系命令
などなど。
3.こんなに違う、マシン命令HotSpot:
iconst_ほげほげ
lconst_ほげほげ
dconst_ほげほげ
Dalvik/ART:
const/4
const/16
const

57.
・Dalvik/ARTとHotSpotでどちらにもあるもの
return系命令
const系命令
if系命令
などなど。
3.こんなに違う、マシン命令
などなど・・・。
（気になる人は命令セッ
トを比較してみて下さい）

58.
・Dalvik/ARTとHotSpotでどちらにもあるもの
return系命令
const系命令
if系命令
などなど。
3.こんなに違う、マシン命令
命令の名称やオペコードの
値は色々違っているのだけ
ど、大体やる処理としては
同じ

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

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

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

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

63.
4.バイナリ(class、dex)
ソースコード
(javaファイル)
dexツール dexファイル
HotSpot VM Dalvik/ART VM
classファイル

64.
☆classファイルフォーマット
1.magic;
2.minor_version;
3.major_version;
4.constant_pool_count;
5.cp_info
constant_pool[constant_pool_count-1];
4.バイナリ(class、dex)

65.
☆classファイルフォーマット
1.magic;
2.minor_version;
3.major_version;
4.constant_pool_count;
5.cp_info
constant_pool[constant_pool_count-1];
4.バイナリ(class、dex)
いわゆるひとつ
のCAFEBABE
.classに必ずある
もの

66.
☆classファイルフォーマット
1.magic;
2.minor_version;
3.major_version;
4.constant_pool_count;
5.cp_info
constant_pool[constant_pool_count-1];
4.バイナリ(class、dex)
クラスファイルの
version

67.
☆classファイルフォーマット
1.magic;
2.minor_version;
3.major_version;
4.constant_pool_count;
5.cp_info
constant_pool[constant_pool_count-1];
4.バイナリ(class、dex)
定数プール
のカウント

68.
☆classファイルフォーマット
1.magic;
2.minor_version;
3.major_version;
4.constant_pool_count;
5.cp_info
constant_pool[constant_pool_count-1];
4.バイナリ(class、dex)
定数プール

69.
☆classファイルフォーマット
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];
4.バイナリ(class、dex)
クラスやフィールドへ
のアクセスフラグ。
publicとかprivateとか
アレ

70.
☆classファイルフォーマット
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];
4.バイナリ(class、dex)
このクラス自身と
継承しているスーパー
クラスの情報

71.
☆classファイルフォーマット
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];
4.バイナリ(class、dex)
interfaceのカウントと
intefefaceの配列

72.
☆classファイルフォーマット
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];
4.バイナリ(class、dex)
フィールドのカウントと
フィールドの配列

73.
☆classファイルフォーマット
14.methods_count;
15.method_info methods[methods_count];
16.attributes_count;
17.attribute_info attributes[attributes_count];
4.バイナリ(class、dex)

74.
☆classファイルフォーマット
14.methods_count;
15.method_info methods[methods_count];
16.attributes_count;
17.attribute_info attributes[attributes_count];
4.バイナリ(class、dex)
メソッドのカウントと
メソッドの配列

75.
☆classファイルフォーマット
14.methods_count;
15.method_info methods[methods_count];
16.attributes_count;
17.attribute_info attributes[attributes_count];
4.バイナリ(class、dex)
attributeという特殊な
もののカウントと
その配列

76.
簡単ですね（？）

77.
☆classファイルフォーマット
・versioningされている
・情報ごとにカウントを持っている
・各情報の配列を持つ
・アクセシビリティの情報も持つ
・ただしバイナリを直接読むのは辛いし
javapで良い気がする
4.バイナリ(class、dex)

78.
続いてdex

79.
☆dexファイルフォーマット
1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
4.バイナリ(class、dex)

80.
☆dexファイルフォーマット
1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
4.バイナリ(class、dex)
ヘッダー情報

81.
☆dexファイルフォーマット
1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
4.バイナリ(class、dex)
文字列定数のID

82.
☆dexファイルフォーマット
1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
4.バイナリ(class、dex)
型情報のID

83.
☆dexファイルフォーマット
1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
4.バイナリ(class、dex)
メソッドの
プロトタイプ情報のID
(DEXでのテンプレート)

84.
☆dexファイルフォーマット
1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
4.バイナリ(class、dex)
フィールド情報のID

85.
☆dexファイルフォーマット
1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
4.バイナリ(class、dex)
メソッド情報のID

86.
☆dexファイルフォーマット
1.header
2.string ids
3.type ids
4.proto_ids
5.field_ids
6.method_ids
7.class_defs
4.バイナリ(class、dex)
クラス定義リスト

87.
☆dexファイルフォーマット
8.call_site_ids
9.method_handles
10.data
11.link_data
4.バイナリ(class、dex)

88.
☆dexファイルフォーマット
8.call_site_ids
9.method_handles
10.data
11.link_data
4.バイナリ(class、dex)
全てcall siteの
参照情報
(call siteはメソッドの場
所的なもの)

89.
☆dexファイルフォーマット
8.call_site_ids
9.method_handles
10.data
11.link_data
4.バイナリ(class、dex)
ハンドリングするメソッド
のリスト

90.
☆dexファイルフォーマット
8.call_site_ids
9.method_handles
10.data
11.link_data
4.バイナリ(class、dex)
全部のデータテーブルを
持つ

91.
☆dexファイルフォーマット
8.call_site_ids
9.method_handles
10.data
11.link_data
4.バイナリ(class、dex)
静的リンクされた情報

92.
☆dexファイルフォーマット
・基本的に持っている情報は同じ
(身も蓋もない)
・ただ並び順も持ち方も違う
・もちろんそれぞれのバイトコードは
それぞれのVMでしか動かない
4.バイナリ(class、dex)

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

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

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

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

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

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

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

100.
☆AOTの場合(ART)
ぼく「アプリインストールしよっと」
ART「あ、これインストール中でもネイティブコードに出来
ますわー」
ART「ネイティブコードにしときますね〜」
ぼく「よし、インストール出来た。使ってみよ」
実行時のオーバーヘッドが少ない！！！
5.ランタイムごとのAOT、JIT、GC

101.
Google
IO 2014
the ART
Runtime
より

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

103.
☆JIT or AOTについて
・HotSpotはJIT/Interpreterを採用
・Dalvik(Android 5.0以前)まではJIT/Interpreter
・ART以降(Android 5.0)はAOTを利用している
5.ランタイムごとのAOT、JIT、GC

104.
☆JIT or AOTについて
・HotSpotはJIT/Interpreterを採用
・Dalvik(Android 5.0以前)まではJIT
・ART以降(Android 5.0)はAOTを利用している
5.ランタイムごとのAOT、JIT、GC
Android 5.0は
2014年から

105.
☆JIT or AOTについて
・HotSpotはJIT/Interpreterを採用
・Dalvik(Android 5.0以前)まではJIT
・ART以降(Android 5.0)はAOTを利用している
5.ランタイムごとのAOT、JIT、GCAOT
JIT
Interpreter
を選べる

106.
☆JIT or AOTについて
・HotSpotはJIT/Interpreterを採用
・Dalvik(Android 5.0以前)まではJIT
・ART以降(Android 5.0)はAOTを利用している
Android 7.0からはAOT + JITという形に
5.ランタイムごとのAOT、JIT、GCAOT
JIT
Interpreter
を選べる

107.
どういうことか

108.
☆Android 5.0のART
ぼく「アプリインストールしよっと」
ART「あ、これインストール中でもネイティブコードに出来
ますわー」
ぼく「インストールめっちゃ長い。電池消費やばい。もうマ
ヂムリ」
(ということもあったらしい)
5.ランタイムごとのAOT、JIT、GC

109.
Google IO 2016
The Evolution of
ARTより

110.
☆Android 7.0のAOT + JIT
ぼく「アプリインストールしよっと」
ART「あ、これインストール中でもネイティブコードに出来
ますわー。でも電池消費するからちょっとだけ。あとは
JITさんに任せますわ」
ぼく「よしインストール出来たし、アプリ使ってみよっと」
5.ランタイムごとのAOT、JIT、GC

111.
☆Android 7.0のAOT + JIT
ぼく「アプリインストールしよっと」
ART「あ、これインストール中でもネイティブコードに出来
ますわー。でも電池消費するからちょっとだけ。あとは
JITさんに任せますわ」
ぼく「よしインストール出来たし、アプリ使ってみよっと」->
ユーザーのストレスが少ない形に
5.ランタイムごとのAOT、JIT、GC

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

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

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

115.
☆HotSpotのAOT
・・・・・・・・・・・・・。
5.ランタイムごとのAOT、JIT、GC

116.
☆HotSpotのAOT
あると思います！！！！
5.ランタイムごとのAOT、JIT、GC

117.
HotSpotのAOT

118.
HotSpotのAOT

119.
HotSpotのAOT

120.
☆JEP295
・Java 9では入らない
・javaコマンドオプションでAOTライブラリを指定
・It uses Graal as the code-generating backend.
5.ランタイムごとのAOT、JIT、GC

121.
☆Graalとは
・Next generation compilation technology
supporting Java, Ruby, R, JavaScript, LLVM, and
more...
というJavaで書かれてるヤバいやつ
5.ランタイムごとのAOT、JIT、GC

122.
99%Javaです！
5.ランタイムごとのAOT、JIT、GC

123.
つづいてGC!

124.
☆GCについて
HotSpotだと
・シリアル GC
・パラレル GC
・CMS GC(Java 9でdeprecated?)
・G1GC(Java 9でデフォルト?)
ココから選ぶことになる
5.ランタイムごとのAOT、JIT、GC

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

126.
5.ランタイムごとのAOT、JIT、GC
☆ARTだと
dalvik.vm.gctypeプロパティを変更するか、-Xgcオプショ
ンで
・CMS GC(デフォルト)
・Semi Space GC(いわゆるコピーGC)
・Generational Semi Space GC(いわゆるコピーGC)
可動オブジェクトを動かす空間
と非可動オブジェクトの空間を
持つ。
移動させてシュッとGC

127.
5.ランタイムごとのAOT、JIT、GC
☆ARTだと
dalvik.vm.gctypeプロパティを変更するか、-Xgcオプショ
ンで
・CMS GC(デフォルト)
・Semi Space GC(いわゆるコピーGC)
・Generational Semi Space GC(いわゆるコピーGC)
こっちはそれを世代別に

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

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

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

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

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

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