104

興味深いのですが、なぜ Sun は JVM をスタックベースにし、Google は DalvikVM をレジスタベースにすることにしたのですか?

JVM は、ターゲット プラットフォームで特定の数のレジスタが利用可能であると想定できないと思います。これは、プラットフォームに依存しないことが想定されているためです。そのため、レジスタの割り当てなどをJITコンパイラに延期するだけです。(間違っていたら訂正してください。)

それで、Android の連中は、「それは効率が悪い。すぐにレジスタ ベースの vm に行きましょう...」と考えましたか? しかし、待ってください。複数の異なる Android デバイスがあります。Dalvik がターゲットにしたレジスタの数は? Dalvik オペコードは、特定の数のレジスタに対してハードコードされていますか?

現在市場に出回っているすべての Android デバイスには、ほぼ同じ数のレジスタがありますか? または、dex の読み込み中にレジスタの再割り当てが実行されますか? これらすべてがどのように組み合わされるのでしょうか。

4

3 に答える 3

70

スタックベースの VM には、Java の設計目標にうまく適合する属性がいくつかあります。

  1. スタックベースの設計では、ターゲット ハードウェア (レジスター、CPU 機能) に関する仮定がほとんどないため、さまざまなハードウェアに VM を簡単に実装できます。

  2. 命令のオペランドの大部分は暗黙的であるため、オブジェクト コードは小さくなる傾向があります。これは、低速のネットワーク リンクを介してコードをダウンロードする場合に重要です。

レジスター・ベースの方式を採用するということは、Dalvik のコード・ジェネレーターがパフォーマンスの高いコードを生成するのに苦労する必要がないことを意味します。非常にレジスタが豊富なアーキテクチャまたはレジスタが不十分なアーキテクチャで実行すると、Dalvik はおそらく不利になりますが、それは通常のターゲットではありません。ARM は非常に中間的なアーキテクチャです。

また、Dalvik の初期バージョンには JIT がまったく含まれていなかったことも忘れていました。命令を直接解釈する場合は、レジスタ ベースのスキームがおそらく解釈パフォーマンスの勝者です。

于 2010-04-27T07:49:48.687 に答える
34

参考文献は見つかりませんが、Sun がスタックベースのバイトコード アプローチを採用したのは、レジスタの少ないアーキテクチャ (IA32 など) で JVM を簡単に実行できるためだと思います。

Dalvik VM Internals from Google I/O 2008 で、Dalvik の作成者であるDan Bornsteinは、プレゼンテーション スライドのスライド 35 で、レジスタ ベースの VM を選択するための次の引数を提供します。

機械の登録

なんで？

  • 命令ディスパッチを避ける
  • 不要なメモリアクセスを避ける
  • 命令ストリームを効率的に消費する (命令ごとのセマンティック密度が高い)

スライド 36:

機械の登録

統計

  • 30% 少ない命令
  • 35% 少ないコード単位
  • 命令ストリームのバイト数が 35% 増加
    • しかし、一度に2つ消費することができます

Bornstein によれば、これは「一連のクラス ファイルを dex ファイルに変換したときに得られる一般的な予想」です。

プレゼンテーションビデオの該当部分は25:00 から始まります。

また、Shi 氏らによる「Virtual Machine Showdown: Stack Versus Registers」という洞察に満ちた論文もあります。(2005)では、スタック ベースとレジスタ ベースの仮想マシンの違いについて説明しています。

于 2014-03-04T17:13:03.380 に答える
13

なぜ Sun が JVM スタックをベースにすることにしたのか、私にはわかりません。Erlangs 仮想マシンである BEAM は、パフォーマンス上の理由からレジスタ ベースです。また、パフォーマンス上の理由から、Dalvik もレジスター ベースのようです。

プロ Android 2から:

Dalvik は、スタックではなく、主にデータ ストレージの単位としてレジスタを使用します。その結果、Google は 30% 少ない命令を実現したいと考えています。

そしてコードサイズに関して：

Dalvik VM は、生成された Java クラス ファイルを取得し、それらを 1 つ以上の Dalvik Executables (.dex) ファイルに結合します。複数のクラス ファイルからの重複した情報を再利用することで、従来の .jar ファイルの容量要件 (非圧縮) を半分に効果的に削減します。たとえば、Android の Web ブラウザー アプリの .dex ファイルは約 200k ですが、同等の圧縮されていない .jar バージョンは約 500k です。目覚まし時計の .dex ファイルは約 50k で、.jar バージョンのサイズの約 2 倍です。

また、 Computer Architecture: A Quantitative Approachも覚えているように、レジスター マシンはスタック ベースのマシンよりもパフォーマンスが優れていると結論付けています。

于 2010-11-09T13:37:47.837 に答える