Dalvik は、 Android オペレーティングシステムでAndroid 用に書かれたアプリケーションを実行する、廃止されたプロセス仮想マシン(VM)です。 [ 1 ] [ a ] Dalvik は、携帯電話やタブレット コンピュータなどのモバイル デバイスで一般的に使用されていた(現在はサポートされていない) Android バージョン4.4 "KitKat"以前の Android ソフトウェア スタックの不可欠な部分であり、スマート TVやウェアラブルなどの一部のデバイスではさらに使用されていました。 Dalvik はオープンソース ソフトウェアであり、元々は Dan Bornstein によって書かれ、アイスランドのEyjafjörðurにある漁村Dalvíkにちなんで名付けられました。[ 2 ] [ 3 ]
Android 用プログラムは一般的にJavaとKotlinで記述され、Java 仮想マシン用のバイトコードにコンパイルされます。その後、Dalvik バイトコードに変換され、( Dalvik 実行可能ファイル) および(最適化 Dalvik 実行可能ファイル) に格納されます。関連する用語として、odexおよびde-odex があり、これらはそれぞれのバイトコード変換に関連付けられています。コンパクトな Dalvik 実行可能ファイル形式は、メモリとプロセッサ速度に制約のあるシステム向けに設計されています。.dex.odex
Dalvik の後継はAndroid Runtime (ART) で、同じバイトコードと .dex ファイル (ただし .odex ファイルは使用しない) を使用し、パフォーマンスの向上を目指して開発されました。この新しいランタイム環境は、Android 4.4 "KitKat" で初めてテクノロジー プレビューとして導入され、[ 4 ] [ 5 ]後のバージョンでは Dalvik を完全に置き換えました。Android 5.0 "Lollipop"は、ART が唯一のランタイムとして含まれる最初のバージョンです。
Dalvik は、開発者の Dan Bornstein がアイスランドの町にちなんで名付けたもので[ 6 ] 、非常に少ない RAM と CPU [ 7 ]を搭載した組み込みデバイスで Java コードを実行するように設計され、最終的には「ヘビーデューティー アプリ」用のC++と「軽量ウィジェットのようなアプリ」用のJavaScript を第一級言語としてサポートし、残りは Java で対応することになっていました。最終的に C++ サポートへの道を開いたAndroid Native Development Kit は、 Dalvik の最初の公開リリース以来存在しています。Bornstein によると、複数のプロセスにわたる実行可能ファイルとライブラリのメモリ マップと、レジスタ ベースのセマンティクスを持つ高速なインタプリタの構築が、バイト ラインされた命令セットと仮想マシンの初期設計の大部分を推進しました。Danger の Sidekick で J2ME を使用した経験から、 BornsteinはAndroidには機能が制限されすぎていると感じました。当時Sunが計画していたIsolatesなどの改善は、Android のデバイス内セキュリティ モデルを壊したため、プロセス分離が実現不可能になりました。 Dalvik VM に関しては、Bornstein は特にダブリンのトリニティ カレッジの Brian Davis らが執筆したThe Case for Register Machines [ 6 ]からインスピレーションを得た。 [ 8 ]
Dalvikは、他のAndroidオープンソースプロジェクトと同様に、 2008年にApache License v2の下でオープンソース化された。[ 9 ]

スタックマシンであるJava仮想マシンとは異なり、Dalvik VMはレジスタベースのアーキテクチャを採用しており、より少ない、しかし一般的に複雑な仮想マシン命令を必要とします。Dalvikプログラムは、Androidアプリケーションプログラミングインターフェース(API)を使用してJavaで記述され、Javaバイトコードにコンパイルされた後、必要に応じてDalvik命令に変換されます。
dxJava .classファイルを .dex 形式に変換するには、と呼ばれるツールが使用されます。 1 つの .dex ファイルには複数のクラスが含まれます。 複数のクラス ファイルで使用される重複する文字列やその他の定数は、スペースを節約するために .dex 出力に 1 回だけ含まれます。 Javaバイト コードも、Dalvik VM で使用される代替命令セットに変換されます。 非圧縮の .dex ファイルは、同じ .class ファイルから派生した圧縮Java アーカイブ(JAR)よりも通常数パーセント小さくなります。 [ 10 ]
Dalvikの実行ファイルは、モバイルデバイスにインストールされる際に再度変更される可能性があります。さらなる最適化を図るため、例えば、特定のデータのバイト順序を入れ替えたり、単純なデータ構造や関数ライブラリをインラインでリンク したり、空のクラスオブジェクトを短絡処理したりすることがあります。
Dalvikは低メモリ要件に最適化されているため、他の標準的なVMとは異なるいくつかの特徴があります。[ 11 ]
Dalvikの設計により、デバイスはVMの複数のインスタンスを効率的に実行できます。[ 12 ] [ 13 ]
Android 2.2「Froyo」では、トレースベースのジャストインタイム(JIT)コンパイルがDalvikに導入され、アプリケーションが実行されるたびに継続的にプロファイリングを行い、頻繁に実行されるバイトコードの短いセグメントをネイティブマシンコードに動的にコンパイルすることで、アプリケーションの実行が最適化されます。Dalvikはアプリケーションの残りのバイトコードを解釈しますが、「トレース」と呼ばれるこれらの短いバイトコードセグメントのネイティブ実行により、パフォーマンスが大幅に向上します。 [ b ]トレースの候補となるヘッドは、コンパイラのフロントエンドで解析段階とバイトコード変換後に識別されます。実行中は変換キャッシュが維持されます。複数のトレースを連結することで、コンパイラとインタプリタ間の同期を減らすことができます。トレースは、単一静的代入形式に変換することで最適化され、デッドストアの削除、変数の折りたたみ、ゲッターとセッターのインライン化などの最適化が可能になります。[ 12 ]

スタックマシンとレジスタベースのアプローチの相対的な利点については、現在も議論が続いている。[ 17 ]
一般的に、スタックベースのマシンは、スタックにデータをロードしたり、そのデータを操作したりするために命令を使用する必要があり、そのため、同じ高水準コードを実装するにはレジスタマシンよりも多くの命令が必要になります。しかし、レジスタマシンの命令はソースレジスタとデスティネーションレジスタをエンコードする必要があるため、命令サイズが大きくなる傾向があります。この違いは、オペコードのディスパッチがコストのかかるVMインタープリタにとって重要であり、ジャストインタイムコンパイルに同様に関連する他の要因も同様に重要です。
2010年にOracle (Javaテクノロジーの所有者)がARMv7デバイスで標準的な非グラフィカルJavaベンチマークを使用して行ったテストでは、 Java SE組み込みのHotSpot VMが、Android 2.2(JITコンパイラを含む最初のAndroidリリース)のJITベースのDalvik VMよりも2~3倍高速であることが示されました。 [ 18 ] 2012年には、学術ベンチマークが同じAndroidボード上でHotSpotとDalvikの3倍の速度差を確認し、DalvikコードがHotSpotよりも小さくないことも指摘しました。[ 19 ]
さらに、2014年3月現在 Android デバイスで実行されたベンチマークでは、同じ Android デバイス上のネイティブ アプリケーションと Dalvik アプリケーションの間で最大 100 倍の速度差が依然として見られます。[ 20 ] 2009 年の初期インタープリタを使用してベンチマークを実行すると、Java Native Interface (JNI) とネイティブ コードの両方で桁違いの高速化が見られました。[ 21 ]
Dalvik はApache License 2.0の条件で公開されています。 [ 22 ] Dalvik は標準 Java ランタイムの上に開発されたものではなく、クリーンルーム実装であると言う人もいます。つまり、標準版またはオープンソース版の Java ランタイムから著作権に基づくライセンス制限を継承していないということです。[ 23 ] Oracleと一部のレビュー担当者はこれに異議を唱えています。[ 24 ]
2010年8月12日、 2009年4月にサン・マイクロシステムズを買収し、Javaの権利を所有するオラクルは、著作権と特許の侵害を主張してグーグルを提訴した。オラクルは、グーグルがAndroidの開発において、オラクルのJava関連の知的財産を故意に、直接的かつ繰り返し侵害したと主張した。 [ c ] 2012年5月、この訴訟の陪審は、グーグルがオラクルの特許を侵害していないと判断し、裁判官は、グーグルが使用したJava APIの構造は著作権の対象ではないと判決を下した。[ 28 ] [ 29 ]当事者は、コピーした9行のコードに対する法定損害賠償額をゼロドルとすることで合意した。[ 30 ] [ 31 ]
ランタイムは [現在の Android バージョンでは] メンテナンスされておらず、利用もできません。そのバイト コード形式は現在 ART で使用されています。
{{cite book}}:|journal=無視されました (ヘルプ){{cite magazine}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)結果から、Android の新しい JIT はインタープリタのみの実装よりも改善されているものの、Android はホットスポットが有効になっている Java SE Embedded のパフォーマンスにまだ及ばないことがわかります。上記の結果からわかるように、Java SE Embedded は Android 2.2 よりも 2 ~ 3 倍速く Java バイトコードを実行できます。
ただし、JITC モードでは、Dakvik は HotSpot より 2.9 倍以上遅く、コード品質が悪くトレースチェーンコードのため、生成されるコードサイズも HotSpot より小さくありません。
JNIを利用することで最大10倍の高速化を実現できます。
「クリーンルーム」実装の定義は、コードを書くエンジニアが、コード、仕様、その他のドキュメントを含む、著作権で保護された元の資料に直接触れることがないというものです。昨日の投稿で述べたように、これはGoogleにとって問題です。なぜなら、プロジェクトに取り組んでいるエンジニアが著作権で保護された資料に直接アクセスしていたという相当な証拠があるからです。
の主張の大部分は、Java.Util.Arrays.rangeCheck()に含まれる9行のコードに基づいています。問題のコードは次のとおりです:...