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/googleoraclejava_apiitjjug.html

本セッションで話題にしないこと




・実践的なVMのパフォーマンスチューニング

Javaパフォーマンスという

本があるので

それを読んでいただければ

おそらく・・・！

本セッションで話題にしないこと

アジェンダ

1. Javaの人にとってのDalvik/ART2.Androidの人にとってのJVM(not Dalvik/ART)3.こんなに違う、マシン命令

4.バイナリ(class、dex)5.ランタイムごとのAOT、JIT、GC6.まとめ

アジェンダ

▷ 1. Javaの人にとってのDalvik/ART2.Androidの人にとってのJVM(not Dalvik/ART)3.こんなに違う、マシン命令


・別に知らなくていい（身も蓋もない）

・知ってた方がプラットフォームを意識した設計・プログラミングが出来るのでは

・HotSpot以外のVMを知ってた方が翻ってHotSpotの理解につながるのでは

1. Javaの人にとってのDalvik/ART

☆今更ながら前提

・現状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/jjugccc-201ibm-sdk-for-java-8




アジェンダ

1. Javaの人にとってのDalvik/ART▷2.Androidの人にとってのJVM(not Dalvik/ART)3.こんなに違う、マシン命令


・JavaもどきとかAndroid Javaとはなぜ言う人がいるか（またそれに対しての対応）

・違いを知る。実機では動かないけどIDEでは動く、なぜ？とか

・なぜHotSpotがあるのにAndroidはVMを独自に用意した？

2.Androidの人にとってのJVM

・言葉が悪い

・JavaであってちょっとJavaでなくてちょっとJavaなのがAndroid・Android Javaぐらいが妥当な表現か

Javaもどき問題

Javaもどき問題

・JLSは満たしているようだが、

JVMSは満たしていない

(歴史的経緯でTCKをパスしていない)・標準ライブラリが違う

例えばjava.beansパッケージに含まれているクラスが少ないなど

アジェンダ

1. Javaの人にとってのDalvik/ART2.Androidの人にとってのJVM(not Dalvik/ART)▷ 3.こんなに違う、マシン命令


ちょっとその前に

・HotSpotはスタックマシン

・Dalvik/ARTは(特殊な)レジスタマシン

スタックマシンは命令を積み上げ

レジスタマシンは命令をレジスタへの登録

Dalvik/ARTの場合はメモリ領域をレジスタと呼んでいる（特殊とはそのあたりのこと）

3.こんなに違う、マシン命令

・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/dalvik-10316622というかTakuya Matsunagaという方がすごい


https://www.slideshare.net/kmt-t/dalvik-10316622



なんで違う？

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 = 0xb6invokeinterface = 0xb7invokestatic =0xb8invokespecial = 0xb9


invoke-virtual = 0x6einvoke-interface = 0x72invoke-static = 0x71new-instance = 0x22



invoke-virtual = 0x6einvoke-interface = 0x72invoke-static = 0x71new-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のマシンアーキテクチャだった

・それにともなって、マシン命令も違う（というより、オペコードの値は違う）

・実行バイナリが違うことも１つ大きな要因だと思います(この後に紹介します)

アジェンダ

1. Javaの人にとってのDalvik/ART2.Androidの人にとってのJVM(not dalvik/ART)3.こんなに違う、マシン命令

▷ 4.バイナリ(class、dex)5.ランタイムごとのAOT、JIT、GC6.まとめ

4.バイナリ(class、dex)

・HotSpotはclassファイル

・Dalvik/ARTはdex(Dalvik Executable)ファイル

がそれぞれVMにロードされて

マシンコードになって実行される

4.バイナリ(class、dex)ソースコード(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];





いわゆるひとつのCAFEBABE.classに必ずあるもの




クラスファイルのversion




定数プールのカウント




定数プール


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とかアレ




このクラス自身と継承しているスーパークラスの情報




interfaceのカウントとintefefaceの配列




フィールドのカウントとフィールドの配列


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





メソッドのカウントとメソッドの配列




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

簡単ですね（？）


・versioningされている

・情報ごとにカウントを持っている

・各情報の配列を持つ

・アクセシビリティの情報も持つ

・ただしバイナリを直接読むのは辛いし

javapで良い気がする


続いてdex

☆dexファイルフォーマット

1.header 2.string ids 3.type ids 4.proto_ids 5.field_ids 6.method_ids 7.class_defs





ヘッダー情報




文字列定数のID




型情報のID




メソッドのプロトタイプ情報のID(DEXでのテンプレート)




フィールド情報のID




メソッド情報のID




クラス定義リスト


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





全てcall siteの参照情報(call siteはメソッドの場所的なもの)




ハンドリングするメソッドのリスト




全部のデータテーブルを持つ




静的リンクされた情報


・基本的に持っている情報は同じ

(身も蓋もない)・ただ並び順も持ち方も違う

・もちろんそれぞれのバイトコードは

それぞれのVMでしか動かない


アジェンダ


4.バイナリ(class、dex)▷ 5.ランタイムごとのAOT、JIT、GC6.まとめ

・JIT(Just-In-Time Compiler)とは

実行時にネイティブコードにコンパイルする

・AOT(Ahead-Of-Time Compiler)とは

実行前にネイティブコードにコンパイルする

・GCとは

ガベージコレクション。JavaもAndroidも共通のメモリ管理の機構

5.ランタイムごとのAOT、JIT、GC

・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より

ココ！！！


☆JIT or AOTについて

・HotSpotはJIT/Interpreterを採用

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




・Dalvik(Android 5.0以前)まではJIT・ART以降(Android 5.0)はAOTを利用している

5.ランタイムごとのAOT、JIT、GCAndroid 5.0は2014年から




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




Android 7.0からはAOT + JITという形に

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

どういうことか

☆Android 5.0のARTぼく「アプリインストールしよっと」


ぼく「インストールめっちゃ長い。電池消費やばい。もうマヂムリ」

(ということもあったらしい)


Google IO 2016The Evolution of ARTより

☆Android 7.0のAOT + JITぼく「アプリインストールしよっと」

ART「あ、これインストール中でもネイティブコードに出来ますわー。でも電池消費するからちょっとだけ。あとはJITさんに任せますわ」

ぼく「よしインストール出来たし、アプリ使ってみよっと」


☆Android 7.0のAOT + JITぼく「アプリインストールしよっと」

ART「あ、これインストール中でもネイティブコードに出来ますわー。でも電池消費するからちょっとだけ。あとはJITさんに任せますわ」

ぼく「よしインストール出来たし、アプリ使ってみよっと」->ユーザーのストレスが少ない形に


DalvikとARTの違いはこのあたり

・そもそもDalvikはシングルコア向けに作られていた

・Androidは8コアになった。だからART・スイープのpauseがARTの方が短くなったらしい

・dexファイルが動く、など基本的なところは同じ

・違いはAOTが入ったこと、GC改善、ロギング改善など


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

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

☆HotSpotのAOT

・・・・・・・・・・・・・。


☆HotSpotのAOT

あると思います！！！！


HotSpotのAOT

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!

☆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


5.ランタイムごとのAOT、JIT、GCART


アジェンダ


4.バイナリ(class、dex)5.ランタイムごとのAOT、JIT、GC▷ 6.まとめ

なんのためのDalvik、ARTか・Androidに最適化されている

・ARTは最近？のAndroid端末に合わせての更なる最適化・当たり前だがプラットフォームが違えば要求される実行環境(VM)も違う

・プラットフォームを優先した結果独自VMとして別々の道を歩むことになった

6.まとめ

・プラットフォームに合わせるために犠牲はつきもの？

->Android SDKに無くて、JDKにあるものはあるが、バランスを考えてそうなっている

・どちらも頑張った結果

->HotSpotはPCマシン(あるいはサーバー)前提で最適化を頑張った結果、Dalvik/ARTはAndroidプラットフォーム前提で頑張った結果

6.まとめ

・VMをブラックボックスとして扱う技術者にならないように(自戒を込めて)・どう動いているのか意識して、その上でIDEに任せて楽をしたい

・何が起こってるか理解できないと問題を解決できない

6.まとめ

Technology

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