Dalvik (ソフトウェア)

ダルヴィク
原作者	ダン・ボーンスタイン
リポジトリ	android.googlesource.com/platform/dalvik ;
オペレーティング·システム	Linuxカーネル
プラットフォーム	アンドロイド
後継	Android ランタイム
タイプ	仮想マシン
ライセンス	Apache ライセンス2.0
Webサイト	source.android.com/devices/tech/dalvik/index.html

Dalvik は、Android オペレーティングシステムでAndroid 用に記述されたアプリケーションを実行する廃止されたプロセス仮想マシン(VM)です。 ^[1] (Dalvik バイトコード形式は配布形式として引き続き使用されていますが、新しい Android バージョンでは実行時には使用されていません。) Dalvik は、(現在はサポートされていない) Android バージョン 4.4「KitKat」およびそれ以前の Android ソフトウェアスタックの不可欠な部分であり、携帯電話やタブレットコンピューターなどのモバイルデバイス、さらにはスマート TVやウェアラブルなどの一部のデバイスで一般的に使用されていました。Dalvik はオープンソースソフトウェアで、もともと Dan Bornstein によって作成され、アイスランドのエイヤフィヨルズルにある漁村Dalvíkにちなんで名付けられました。^[2]^[3]

Android 用のプログラムは通常Javaで書かれ、Java 仮想マシン用のバイトコードにコンパイルされます。その後、Dalvik バイトコードに変換され、( Dalvik EXecutable ) ファイルと( Optimized Dalvik EXecutable ) ファイルに保存されます。関連用語のodexとde-odex は、それぞれのバイトコード変換に関連付けられています。コンパクトな Dalvik Executable 形式は、メモリとプロセッサ速度の点で制約のあるシステム向けに設計されています。 .dex.odex

Dalvikの後継はAndroid Runtime (ART)で、同じバイトコードと.dexファイル（ただし.odexファイルは使用しない）を使用し、パフォーマンスの向上を目指しています。新しいランタイム環境は、Android 4.4「KitKat」でテクノロジープレビューとして初めて搭載され、^[4]^[5]以降のバージョンではDalvikに完全に置き換えられました。Android 5.0「Lollipop」は、ARTが唯一のランタイムとして搭載された最初のバージョンです。

歴史

Dalvikは、作成者のダン・ボーンスタインによってアイスランドの町にちなんで名付けられました^[6] 。RAMとCPUが非常に少ない組み込みデバイスでJavaコードを実行するために設計されました^[7]。最終的には、「ヘビーデューティーアプリ」向けにC ++を、「軽量ウィジェットのようなアプリ」向けにJavaScriptを第一級言語としてサポートし、Javaが残りに対応しました。最終的にC++サポートへの道を開いたAndroid Native Development Kitは、Dalvikの最初の公開リリースから存在していました。ボーンスタインによると、複数のプロセスにわたる実行可能ファイルとライブラリのメモリマッピングと、レジスタベースのセマンティクスを備えたより高速なインタープリターの構築は、バイト境界整列命令セットと仮想マシンの初期の設計の多くを推進しました。サイドキックでJ2MEを扱った経験から、ボーンスタインは、Androidには J2MEが簡素化されすぎていて、かなり制約が多いことに気づきました。 Dalvik VMに関しては、Bornsteinは特にダブリンのトリニティ・カレッジのブライアン・デイビスらが執筆した「The Case for Register Machines ^」[6]からインスピレーションを得ました。^[8]

Dalvikは2008年にAndroidオープンソースプロジェクトの他の部分と同様にApache License v2の下でオープンソース化されました。^[9]

建築

スタックマシンであるJava 仮想マシンとは異なり、Dalvik VM は、より少ない、通常はより複雑な仮想マシン命令を必要とするレジスタベースのアーキテクチャを使用します。Dalvik プログラムは、Android アプリケーションプログラミングインターフェース(API)を使用して Java で記述され、Java バイトコードにコンパイルされ、必要に応じて Dalvik 命令に変換されます。

と呼ばれるツールはdx、Java .classファイルを .dex 形式に変換するために使用されます。複数のクラスが1 つの .dex ファイルに含まれます。複数のクラスファイルで使用される重複した文字列やその他の定数は、スペースを節約するために .dex 出力に 1 回だけ含まれます。Javaバイトコードも、Dalvik VM で使用される代替命令セットに変換されます。圧縮されていない .dex ファイルは通常、同じ .class ファイルから派生した圧縮された Java アーカイブ(JAR)よりもサイズが数パーセント小さくなります。^[10]

Dalvik 実行ファイルは、モバイルデバイスにインストールされると再度変更される可能性があります。さらに最適化するために、特定のデータのバイト順序を入れ替えたり、単純なデータ構造と関数ライブラリをインラインでリンクしたり、空のクラスオブジェクトを短絡したりするなどの処理が行われる可能性があります。

Dalvikは低メモリ要件に最適化されており、他の標準的なVMとは異なるいくつかの特徴を持っています。^[11]

VM は、より少ないスペースを使用するようにスリム化されました。
インタープリタを簡素化するために、定数プールは32 ビットのインデックスのみを使用するように変更されました。
標準のJava バイトコードは8 ビットスタック命令を実行します。ローカル変数は、別の命令によってオペランドスタックにコピーするか、オペランドスタックからコピーする必要があります。代わりに、Dalvik はローカル変数に直接作用する独自の16 ビット命令セットを使用します。ローカル変数は通常、 4 ビットの「仮想レジスタ」フィールドによって選択されます。これにより、Dalvik の命令数が減り、インタープリタの速度が向上します。

Googleによれば、Dalvikの設計により、デバイスはVMの複数のインスタンスを効率的に実行できるようになるという。^[12]

Android 2.2「Froyo」では、トレースベースのジャストインタイム（JIT）コンパイルがDalvikに導入され、アプリケーションが実行されるたびに継続的にプロファイリングし、頻繁に実行されるバイトコードの短いセグメントをネイティブマシンコードに動的にコンパイルすることで、アプリケーションの実行が最適化されました。Dalvikはアプリケーションのバイトコードの残りの部分を解釈しますが、「トレース」と呼ばれるこれらの短いバイトコードセグメントのネイティブ実行により、パフォーマンスが大幅に向上します。^[13]^[14]^[15]

パフォーマンス

スタックマシンとレジスタベースのアプローチの相対的な利点については、現在も議論が続いている。^[16]

一般的に、スタックベースのマシンは、命令を使用してスタックにデータをロードし、そのデータを操作する必要があるため、同じ高レベルコードを実装するにはレジスタマシンよりも多くの命令が必要です。ただし、レジスタマシンの命令はソースレジスタと宛先レジスタをエンコードする必要があるため、サイズが大きくなる傾向があります。この違いは、オペコードのディスパッチがコストがかかる傾向がある VM インタープリタにとって重要であり、ジャストインタイムコンパイルに同様に関連する他の要因も同様です。

2010年にOracle（Javaテクノロジーの所有者）がARMv7デバイスで標準の非グラフィカルJavaベンチマークを使用して行ったテストでは、 Java SE組み込みのHotSpot VMが Android 2.2（JITコンパイラを搭載した最初のAndroidリリース）のJITベースのDalvik VMよりも2〜3倍高速であることが示されました。 ^{[17] 2012年には、学術的なベンチマークで、同じAndroidボード上の}HotSpotとDalvikの速度が3倍であることが確認され、DalvikコードはHotspotよりも小さくないことも指摘されました。^[18]

さらに、2014年3月時点で^{[アップデート]}、Androidデバイスで実行されたベンチマークでは、同じAndroidデバイス上のネイティブアプリケーションとDalvikアプリケーションの間で最大100倍の速度差が見られました。^[19]^{[独自の研究? ]}^{[不適切な合成? ]} 2009年の初期のインタープリターを使用してベンチマークを実行したところ、Java Native Interface (JNI)とネイティブコードの両方で桁違いの高速化が見られました。^[20]

ライセンスと特許

DalvikはApache License 2.0の条件に基づいて公開されています。^[21]^Dalvikは標準Javaランタイム上での開発ではなくクリーンルーム実装であり^、標準版またはオープン^ソース版のJavaランタイムから著作権ベースのライセンス制限を継承していないという意見もあります。^[22] Oracleと一部のレビュー担当者はこれに異議を唱えています。^[23]

2010年8月12日、 2009年4月にサン・マイクロシステムズを買収し、Javaの権利を所有するオラクルは、著作権と特許の侵害を理由にグーグルを提訴した。オラクルは、グーグルがAndroidの開発において、オラクルのJava関連の知的財産を故意に直接繰り返し侵害したと主張した。[ ^24]^[25]^[26] 2012年5月、この事件の陪審はグーグルがオラクルの特許を侵害していないとの判決を下し、裁判官はグーグルが使用したJava APIの構造は著作権で保護されないとの判決を下した。^[27]^[28]両当事者は、コピーされた9行のコードに対する法定損害賠償をゼロにすることで合意した。 ^[29]^[30]

参照

参考文献

^ 「ART ガベージコレクションのデバッグ」。2015年10 月 6 日閲覧。Dalvikランタイムは [Android の現在のバージョンでは] メンテナンスされておらず、利用できなくなっており、そのバイトコード形式は現在 ART によって使用されています。
^ 名前の由来を記した日記
^ 「Google Calling: Android の内部、gPhone SDK」。onlamp.com。2017年 1 月 10 日時点のオリジナルよりアーカイブ。2008年 2 月 5 日閲覧。
^ Sean Buckley (2013-11-06). 「Android KitKat の「ART」実験により、バッテリー寿命が改善し、アプリが高速化」Engadget . 2014-07-05閲覧。
^ Daniel P. (2013-11-07). 「Android KitKat の実験的な Google ART ランタイムにより、アプリの実行速度が 2 倍に向上」. phonearena.com . 2014-07-05閲覧。
^ ab Dalvik VM の作者 Dan Bornstein 氏とのライブ Q&A。InfoQ。2015年9 月 29 日 – YouTube 経由。
^ Google I/O 2008 - Dalvik 仮想マシンの内部。Google 。2008年 6 月 4 日 – YouTube 経由。
^ Davis, Brian; Beatty, Andrew; Casey, Kevin; Gregg, David; T Waldron, John (2003年6月8日). 「仮想レジスタマシンのケース」(PDF) . Association for Computing Machinery . doi :10.1145/858570.858575. 2024年2月1日時点のオリジナル(PDF)からアーカイブ。
^ Beschizza, Rob (2007年11月12日). 「Android SDK Open For Code」. WIRED . 2024年1月31日時点のオリジナルよりアーカイブ。
^ Bornstein, Dan (2008-05-29). 「Dalvik VM 内部のプレゼンテーション」(PDF) 。p. 22。2017-04-16のオリジナル(PDF)からアーカイブ。2010-08-16に取得。
^ Rose, John (2008-05-31). 「Android と Dalvik について Google I/O で」。2008-06-04 時点のオリジナルよりアーカイブ。2008-06-08に閲覧。
^ Google (2009-04-13). 「What is Android?」. 2009-06-27 時点のオリジナルよりアーカイブ。2009-04-19閲覧。
^ Ben Cheng、Bill Buzbee (2010 年 5 月)。「Android の Dalvik VM 用 JIT コンパイラ」(PDF)。android -app-developer.co.uk。pp . 5–14。2015年 11 月 6 日時点のオリジナル(PDF)からのアーカイブ。2015年3 月 18 日閲覧。
^ Phil Nickinson (2010 年 5 月 26 日). 「Google Android 開発者が Dalvik と Froyo の JIT についてさらに詳しく説明」. androidcentral.com . 2014 年 7 月 14 日時点のオリジナルよりアーカイブ。2014年7 月 8 日閲覧。
^ 「Nexus One は Android 2.2 Froyo を実行しています。2.1 と比べてどれくらい高速ですか? ああ、わずか 450% ほど高速です」。2010 年 5 月 13 日。2010年 5 月 21 日閲覧。
^ Shi, Yunhe; Gregg, David; Beatty, Andrew; Ertl, M. Anton (2005-06-11). 「仮想マシン対決: スタック対レジスタ」(PDF) 。 2009-12-22に閲覧。
^ Vandette, Bob (2010-11-22). 「Java SE Embedded のパフォーマンスと Android 2.2 の比較」。Oracle Corporation。2011-06-28にオリジナルからアーカイブ。2011-09-04に取得。結果から、Android の新しい JIT はインタープリターのみの実装よりも改善されているものの、Android は依然として Hotspot 対応の Java SE Embedded のパフォーマンスに遅れをとっていることがわかります。上記の結果からわかるように、Java SE Embedded は Android 2.2 よりも 2 ～ 3 倍高速に Java バイトコードを実行できます。
^ Hyeong-Seok Oh、Beom-Jun Kim、Hyung-Kyu Choi、Soo-Mook Moon (2012)。リアルタイムおよび組み込みシステム向け Java テクノロジに関する第 10 回国際ワークショップの議事録 - JTRES '12。Association for Computing Machinery。p . 115。doi : 10.1145 / 2388936.2388956。ISBN 9781450316880. S2CID 36316611。ただし、JITC モードでは、Dakvik は HotSpot よりも 2.9 倍以上遅く、コード品質とトレースチェーンコードが悪いため、生成されるコードサイズは HotSpot よりも小さくなりません。
^ 「Top AndEBench Scores」 www.eembc.org . 2014年3月23日閲覧。
^ Batyuk, Leonid; Schmidt, Aubrey-Derrick; Schmidt, Hans-Gunther; Camtepe, Ahmet; Albayrak, Sahin (2009-04-29). 「Android でのネイティブ Linux アプリケーションの開発とベンチマーク」。MobileWirelessミドルウェア、オペレーティングシステム、およびアプリケーション。コンピュータサイエンス、社会情報学、および通信工学研究所の講義ノート。第 7 巻。pp. 381–392。Bibcode : 2009mmos.book..381B。doi :10.1007 / 978-3-642-01802-2_28。ISBN 978-3-642-01801-5. S2CID 12131309。結果によると、ネイティブ C アプリケーションは、Dalvik VM で実行される同一のアルゴリズムよりも最大 30 倍高速化できます。Java アプリケーションは、JNI を利用すると最大 10 倍高速化できます。
^ 「ソースツリーのダウンロード - Android オープンソース」。Android.git.kernel.org。2009 年 4 月 17 日時点のオリジナルよりアーカイブ。2012 年 6 月 7 日閲覧。
^ ガーリング、カレブ。「GoogleとOracleの『専門家』がAndroidのJava Mimicをめぐって対立」Wired。
^ Ed Bott (2011 年 9 月 8 日)。「Google が語る Java と Android の本当の歴史」。ZDNet。2011年11 月 27 日閲覧。「クリーンルーム」実装の定義は、コードを書くエンジニアが、コード、仕様、その他のドキュメントを含む、著作権で保護されたオリジナルの資料に直接触れないことです。昨日の投稿で述べたように、これは Google にとって問題です。プロジェクトに携わるエンジニアが著作権で保護された資料に直接アクセスしていたという確かな証拠があるからです。
^ 「Oracle、AndroidデバイスにおけるJavaをめぐりGoogleを提訴」 digitaltrends.com. 2010-08-13 . 2011-08-08閲覧。
^ James Niccolai (2010-08-12). 「Oracle、AndroidでのJava使用をめぐってGoogleを訴える」Computerworld . 2010-08-13閲覧。
^ Mark Hachman (2010-08-13). 「Oracle、Android Java 使用に関して Google を訴える」. PC Magazine . Ziff Davis .
^ Josh Lowensohn (2012 年 5 月 23 日)。「陪審員、Google の Oracle 特許侵害を否定」ZDNet。2012年 5 月 25 日閲覧。
^ Joe Mullin (2012 年 5 月 31 日)。「Google が重要な API 判決で勝利、Oracle の訴訟は大敗」Ars Technica。2012年 6 月 1 日閲覧。
^ Niccolai, James (2012年6月20日). 「Oracle、Google訴訟で損害賠償「ゼロ」に同意し、控訴を検討」。2023年4月1日時点のオリジナルよりアーカイブ。 2012年6月23日閲覧。
^ Adam Outler (2012 年 5 月 16 日)。「Oracle 対 Google 裁判の最新情報」。2013 年 5 月 16 日のオリジナルからアーカイブ。2013 年1 月 18 日閲覧。Oracleの主張の大部分は、Java.Util.Arrays.rangeCheck() に含まれる 9 行のコードに基づいています。問題のコードは次のとおりです。...

外部リンク

Dalvik バイトコード –命令セットの公式 Android ドキュメント
Dex 実行可能ファイル形式 – 公式 Android ドキュメント
YouTubeの「Android の Dalvik VM 用 JIT コンパイラ」、Google I/O 2010、Ben Cheng と Bill Buzbee 著
Dalvik VM 内部構造、 Wayback Machineに 2010-03-01 にアーカイブ、Google I/O 2008、Dan Bornstein 著
8 億ドルの価値のある質問: 商標と著作権の違いは何ですか?

[1] 「ART ガベージコレクションのデバッグ」。2015年10 月 6 日閲覧。Dalvikランタイムは [Android の現在のバージョンでは] メンテナンスされておらず、利用できなくなっており、そのバイトコード形式は現在 ART によって使用されています。

[2] 名前の由来を記した日記

[onlamp-3] 「Google Calling: Android の内部、gPhone SDK」。onlamp.com。2017年 1 月 10 日時点のオリジナルよりアーカイブ。2008年 2 月 5 日閲覧。

[4] Sean Buckley (2013-11-06). 「Android KitKat の「ART」実験により、バッテリー寿命が改善し、アプリが高速化」Engadget . 2014-07-05閲覧。

[5] Daniel P. (2013-11-07). 「Android KitKat の実験的な Google ART ランタイムにより、アプリの実行速度が 2 倍に向上」. phonearena.com . 2014-07-05閲覧。

[danama-6] Dalvik VM の作者 Dan Bornstein 氏とのライブ Q&A。InfoQ。2015年9 月 29 日 – YouTube 経由。

[dan08-7] Google I/O 2008 - Dalvik 仮想マシンの内部。Google 。2008年 6 月 4 日 – YouTube 経由。

[8] Davis, Brian; Beatty, Andrew; Casey, Kevin; Gregg, David; T Waldron, John (2003年6月8日). 「仮想レジスタマシンのケース」(PDF) . Association for Computing Machinery . doi :10.1145/858570.858575. 2024年2月1日時点のオリジナル(PDF)からアーカイブ。

[9] Beschizza, Rob (2007年11月12日). 「Android SDK Open For Code」. WIRED . 2024年1月31日時点のオリジナルよりアーカイブ。

[10] Bornstein, Dan (2008-05-29). 「Dalvik VM 内部のプレゼンテーション」(PDF) 。p. 22。2017-04-16のオリジナル(PDF)からアーカイブ。2010-08-16に取得。

[11] Rose, John (2008-05-31). 「Android と Dalvik について Google I/O で」。2008-06-04 時点のオリジナルよりアーカイブ。2008-06-08に閲覧。

[12] Google (2009-04-13). 「What is Android?」. 2009-06-27 時点のオリジナルよりアーカイブ。2009-04-19閲覧。

[13] Ben Cheng、Bill Buzbee (2010 年 5 月)。「Android の Dalvik VM 用 JIT コンパイラ」(PDF)。android -app-developer.co.uk。pp . 5–14。2015年 11 月 6 日時点のオリジナル(PDF)からのアーカイブ。2015年3 月 18 日閲覧。

[14] Phil Nickinson (2010 年 5 月 26 日). 「Google Android 開発者が Dalvik と Froyo の JIT についてさらに詳しく説明」. androidcentral.com . 2014 年 7 月 14 日時点のオリジナルよりアーカイブ。2014年7 月 8 日閲覧。

[15] 「Nexus One は Android 2.2 Froyo を実行しています。2.1 と比べてどれくらい高速ですか? ああ、わずか 450% ほど高速です」。2010 年 5 月 13 日。2010年 5 月 21 日閲覧。

[16] Shi, Yunhe; Gregg, David; Beatty, Andrew; Ertl, M. Anton (2005-06-11). 「仮想マシン対決: スタック対レジスタ」(PDF) 。 2009-12-22に閲覧。

[17] Vandette, Bob (2010-11-22). 「Java SE Embedded のパフォーマンスと Android 2.2 の比較」。Oracle Corporation。2011-06-28にオリジナルからアーカイブ。2011-09-04に取得。結果から、Android の新しい JIT はインタープリターのみの実装よりも改善されているものの、Android は依然として Hotspot 対応の Java SE Embedded のパフォーマンスに遅れをとっていることがわかります。上記の結果からわかるように、Java SE Embedded は Android 2.2 よりも 2 ～ 3 倍高速に Java バイトコードを実行できます。

[18] Hyeong-Seok Oh、Beom-Jun Kim、Hyung-Kyu Choi、Soo-Mook Moon (2012)。リアルタイムおよび組み込みシステム向け Java テクノロジに関する第 10 回国際ワークショップの議事録 - JTRES '12。Association for Computing Machinery。p . 115。doi : 10.1145 / 2388936.2388956。ISBN 9781450316880. S2CID 36316611。ただし、JITC モードでは、Dakvik は HotSpot よりも 2.9 倍以上遅く、コード品質とトレースチェーンコードが悪いため、生成されるコードサイズは HotSpot よりも小さくなりません。

[19] 「Top AndEBench Scores」 www.eembc.org . 2014年3月23日閲覧。

[20] Batyuk, Leonid; Schmidt, Aubrey-Derrick; Schmidt, Hans-Gunther; Camtepe, Ahmet; Albayrak, Sahin (2009-04-29). 「Android でのネイティブ Linux アプリケーションの開発とベンチマーク」。MobileWirelessミドルウェア、オペレーティングシステム、およびアプリケーション。コンピュータサイエンス、社会情報学、および通信工学研究所の講義ノート。第 7 巻。pp. 381–392。Bibcode : 2009mmos.book..381B。doi :10.1007 / 978-3-642-01802-2_28。ISBN 978-3-642-01801-5. S2CID 12131309。結果によると、ネイティブ C アプリケーションは、Dalvik VM で実行される同一のアルゴリズムよりも最大 30 倍高速化できます。Java アプリケーションは、JNI を利用すると最大 10 倍高速化できます。

[21] 「ソースツリーのダウンロード - Android オープンソース」。Android.git.kernel.org。2009 年 4 月 17 日時点のオリジナルよりアーカイブ。2012 年 6 月 7 日閲覧。

[22] ガーリング、カレブ。「GoogleとOracleの『専門家』がAndroidのJava Mimicをめぐって対立」Wired。

[23] Ed Bott (2011 年 9 月 8 日)。「Google が語る Java と Android の本当の歴史」。ZDNet。2011年11 月 27 日閲覧。「クリーンルーム」実装の定義は、コードを書くエンジニアが、コード、仕様、その他のドキュメントを含む、著作権で保護されたオリジナルの資料に直接触れないことです。昨日の投稿で述べたように、これは Google にとって問題です。プロジェクトに携わるエンジニアが著作権で保護された資料に直接アクセスしていたという確かな証拠があるからです。

[24] 「Oracle、AndroidデバイスにおけるJavaをめぐりGoogleを提訴」 digitaltrends.com. 2010-08-13 . 2011-08-08閲覧。

[25] James Niccolai (2010-08-12). 「Oracle、AndroidでのJava使用をめぐってGoogleを訴える」Computerworld . 2010-08-13閲覧。

[26] Mark Hachman (2010-08-13). 「Oracle、Android Java 使用に関して Google を訴える」. PC Magazine . Ziff Davis .

[27] Josh Lowensohn (2012 年 5 月 23 日)。「陪審員、Google の Oracle 特許侵害を否定」ZDNet。2012年 5 月 25 日閲覧。

[28] Joe Mullin (2012 年 5 月 31 日)。「Google が重要な API 判決で勝利、Oracle の訴訟は大敗」Ars Technica。2012年 6 月 1 日閲覧。

[damages-29] Niccolai, James (2012年6月20日). 「Oracle、Google訴訟で損害賠償「ゼロ」に同意し、控訴を検討」。2023年4月1日時点のオリジナルよりアーカイブ。 2012年6月23日閲覧。

[nine_lines_of_code-30] Adam Outler (2012 年 5 月 16 日)。「Oracle 対 Google 裁判の最新情報」。2013 年 5 月 16 日のオリジナルからアーカイブ。2013 年1 月 18 日閲覧。Oracleの主張の大部分は、Java.Util.Arrays.rangeCheck() に含まれる 9 行のコードに基づいています。問題のコードは次のとおりです。...