なぜJVMスタックベースとDalvik VMレジスタベースなのですか?


98

私は好奇心旺盛ですが、なぜSunはJVMをスタックベースにすることに決め、GoogleはDalvikVMをレジスタベースにすることに決めたのですか?

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

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

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


5
DalvikVMをレジスターベースにするというGoogleの決定はありましたか?DalvikVMは、GoogleがAndroid Inc.を取得する前に実装されたと思います
RoboAlex 2013

1
もちろんです。(質問にはあまり関係ありません;)
aioobe

回答:


68

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

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

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

レジスタベースのスキームを採用することは、Dalvikのコードジェネレーターがパフォーマンスの高いコードを生成するためにそれほど努力する必要がないことをおそらく意味します。非常にレジスターが豊富なアーキテクチャーまたはレジスターが少ないアーキテクチャーで実行すると、Dalvikがハンディキャップになる可能性がありますが、それは通常のターゲットではありません。ARMは非常に中途半端なアーキテクチャーです。


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


1
面白いですね。では、DalvikVMはターゲットデバイス上のレジスタの最小数を想定していますか?
aioobe 2010

1
また、「軽量」なOSであるため、ラップトップにAndroidをインストールしている人もいることを読みました。ラップトップがARMでなく、おそらく多くのレジスターを持つアーキテクチャーを持っている場合、それは悪い考えのように思われますか?
aioobe 2010

2
わかりました、私はdexバイトコードが無限レジスタマシンの観点から定義されていることを学びました。効率に関して言えば、それはほとんどメモリフットプリントに関するもののようです。
aioobe 2010

1
Dalvikが無限レジスタベースであるのか、固定レジスタファイルサイズであるのかを思い出せませんでした。無限の場合、実行しているコードに「十分な」レジスターがあるアーキテクチャーで最適に実行される傾向があります。
マークベッシー2010

より詳細な説明はここで見つけることができます:markfaction.wordpress.com/2012/07/15/...
noego

31

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

Dalvik VMの内部 GoogleのI / O 2008から、のDalvik作成者ダンBornsteinはのスライド35にレジスタベースのVMを選択するための次の引数与えプレゼンテーションスライドを

マシンを登録

どうして?

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

そしてスライド36:

マシンを登録

統計

  • 指示を30%削減
  • コード単位を35%削減
  • 命令ストリームのバイトが35%増加
    • でも一度に2つ消費します

ボーンスタインによれば、これは「クラスファイルのセットをdexファイルに変換するときに見つけることができる一般的な期待」です。

プレゼンテーションビデオの関連部分は25:00に始まります。

Shi et al。による「仮想マシンの対決:スタックとレジスター」というタイトルの洞察に満ちた論文もあります。(2005)、スタックベースとレジスタベースの仮想マシンの違いを探ります。


13

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

Pro Android 2から:

Dalvikは、スタックではなく、主にデータストレージの単位としてレジスタを使用します。Googleは、結果として30%少ない指示を達成することを望んでいます。

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

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

そして、私がコンピュータアーキテクチャを覚えているように:定量的アプローチは、レジスタマシンはスタックベースのマシンよりもパフォーマンスが良いと結論付けています。


2
推測しなければならないのであれば、Sunはレジスタマシンよりも実装が簡単なため、JVMスタックをベースにすることにしたと思います。(しかし、ここに記されているように、重要なパフォーマンスコストがかかります。)
Mason Wheeler

参照は見つかりませんが、Sunはスタックベースのバイトコードアプローチを選択したと思います。低レジスタアーキテクチャでJVMを簡単に実行できるためです。
Flow

1
ハードウェアISAの場合、はいレジスターマシンが勝ちました。基本的にすべてのCPU /マイクロコントローラーはレジスターマシンです。アキュムレータだけでなく、1つまたは2つのポインタレジスタまたはインデックスレジスタのように、レジスタが非常に少ないものもありますが、それでも計算理論の意味ではレジスタマシンに似ています。ただし、ここではインタプリタされる VMについて話しているので、「レジスタファイル」がある場合、実際にはメモリに存在します。ネイティブマシンコードにJITコンパイルしない限り。スタックよりもregの方が速いため、理由は大きく異なります。
Peter Cordes
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.