私が見た正当な理由は、AndroidでJavaバイトコードを「Bastardizing」することはパフォーマンスでした。（別の理由があると思います。）しかし、バイトコードを変更することで、Jazelle mootなどのハードウェアアクセラレーションテクノロジが作成されなかったため、モバイルJavaプラットフォームで利用できるパフォーマンスが実際に低下しましたか？
ターゲットプラットフォームがARMベースのモバイルプラットフォームであることを知っていると、直感に反しているように見えます。他のCPUアーキテクチャでパフォーマンスが向上する可能性がありますが、ARMとJazelleに直面しているようです。
Javaのパフォーマンスにどのような量的な影響がありますか？
それは実際にパフォーマンスを向上させますか？もしそうなら、どのように？
他のプラットフォームへの影響は何ですか？（つまり、x86、mips、yadda、yadda、yadda ...）
はい、DalvikはJazelleを役に立たなくします。唯一の質問は、Jazelleが最初から有用だったのか、それとも90％のマーケティングの誇大宣伝なのかということです。優れたJITまたはAOT（事前）コンパイラは、特殊な命令を使用しようとするよりもはるかに優れたパフォーマンスを提供する傾向があります。Dalvikのレジスタベースのアプローチは、従来のJavaバイトコードインタープリターよりも高速である可能性がありますが、インタープリターとJITの違いがわずかである場合。うまくいけば、Androidの次のバージョンの1つにJITがあります。
最先端のガベージコレクターとオプティマイザーを備えた優れた仮想マシンを作成するには、約5〜10年かかります。Sun（およびMicrosoft）はそれらの年月を過ごしました。グーグルはしていません。うまくいけば、彼らはそれに投資し続け、いつの日かAndroid Javaコードが本来よりも90％遅くならないようにするでしょう。
ほとんどの仮想マシンやスタックマシンである真のJavaVMとは異なり、DalvikVMはレジスタベースのアーキテクチャです。
低メモリ要件に最適化されているDalvikには、他の標準VMとは異なるいくつかの特定の特性があります。
- VMは、より少ないスペースを使用するようにスリム化されました。
- Dalvikにはジャストインタイムコンパイラはありません。
- インタプリタを簡素化するために、定数プールが32ビットインデックスのみを使用するように変更されました。
- Javaバイトコードではなく、独自のバイトコードを使用します。
さらに、Dalvikは、デバイスがVMの複数のインスタンスを効率的に実行できるように設計されています。
編集：ウィキペディア：オープンハンドセットアライアンスを参照してください。創設メンバーには、Intel、Motorola、Qualcomm、TexasInstrumentsが含まれます。ARMは1年後の2008年12月に参加しました。したがって、オープンソースのiPhone / Blackberryの競合他社を作成することが目標であったときに、これらの企業が当時の非会員までに独自のテクノロジーに依存することは意味がなかったと思います。
私は実際、Dalvikは実行効率よりもスペース効率を目的としているという印象を受けました。ウィキペディアからも：
圧縮されていない.dexファイルは、通常、同じ.classファイルから派生した圧縮された.jar（Javaアーカイブ）よりもサイズが数パーセント小さくなります。
現在の電話はJazelleをサポートするARMを使用している可能性がありますが、今後は必ずしもそうとは限りません。
ウィキペディアからも（警告：伝聞）：
公開されている仕様は非常に不完全であり、Jazelleを使用するJVMをサポートできるオペレーティングシステムコードを作成するのに十分です。宣言された意図は、JVMソフトウェアのみがハードウェアインターフェイスの詳細に依存する必要がある（または依存することが許可されている）ことです。この緊密なバインディングにより、他のソフトウェアに影響を与えることなく、ハードウェアとJVMを一緒に進化させることができます。事実上、これにより、ARMホールディングスはどのJVMがJazelleを利用できるかをかなり制御できます。また、オープンソースJVMがJazelleを使用するのを防ぎます。
彼らがDalvikにJITterを追加すると、それはすべて論点になります。