仮想マシンとバイトコード実行（スタック型VSレジスタ型）

バイトコードという計算機モデル

バイトコードを実行する仮想マシン（VM）は、物理 CPU を模した抽象的な計算機です。命令セットとオペランドの受け渡し規約を自前で定義し、ホスト CPU 上のインタプリタループがそれを1命令ずつ解釈します。この受け渡し規約こそが、VM 設計の根幹を二分する論点です。

• スタック型 VM — オペランドを置く場所を持たず、暗黙のオペランドスタックを介して値を授受します。代表は JVM、CPython、WebAssembly。
• レジスタ型 VM — 命令そのものに仮想レジスタ番号を書き込み、値の置き場を明示します。代表は Android の Dalvik、Lua 5、Erlang の BEAM。

両者は表現力としては等価（チューリング完全）ですが、同じ計算を何個の命令で・どんな形で表すかが決定的に異なります。スタックの基礎はデータ構造、機械語への翻訳全般はコンパイルとインタプリタも参照してください。

同じ式を両モデルで表す

a + b を計算して変数 c に代入する処理を、両者のバイトコードで書き比べます。

スタック型（JVM風）           レジスタ型（Dalvik風）
iload a   # a をpush          add r2, r0, r1
iload b   # b をpush          # r0=a, r1=b, 結果を r2 へ
iadd      # 2つpop→和をpush
istore c  # popして c へ

スタック型は4命令、レジスタ型は1命令です。スタック型では各オペランドを「いったんスタックに積む」ための load 命令が必ず先行し、演算結果も一度スタックに戻ります。対してレジスタ型は、ソース2つとデスティネーション1つを1命令にまとめて符号化できます。命令あたりの仕事量（密度）が高いのがレジスタ型の本質です。

命令ディスパッチが性能を握る

インタプリタの実行時間の大半は、命令ディスパッチ——「現在の命令を実行し、次の命令の処理コードへ飛ぶ」操作——が占めます。素朴な実装は次のループです。

while (1) {
    opcode = code[pc++];
    switch (opcode) {       /* この分岐が要 */
        case OP_IADD: ...; break;
        case OP_ILOAD: ...; break;
        /* ... */
    }
}

この switch は、CPU から見ると毎回行き先の変わる間接分岐です。分岐予測器は直前の履歴から飛び先を推測しますが、バイトコード列は命令種が不規則に並ぶため予測が当たりにくく、予測ミスのたびにパイプラインがストールします。ここで効いてくるのが命令数の差です。レジスタ型は同じ計算をより少ない命令で表すため、ループの周回数＝ディスパッチ回数自体が減り、予測ミスの絶対数も減ります。Dalvik や Lua がスタック型より速いとされる主因はこれです。

ディスパッチ手法そのものの最適化

ディスパッチ自体を速くする工夫は、スタック型・レジスタ型の別とは独立に効きます。代表がダイレクトスレッディングで、各命令の末尾に「次命令の処理コードへ直接ジャンプする」コードを置きます。GCC の computed goto（ラベルアドレスを値として扱う拡張）で実装され、CPython もこの手法を採用しています。

/* computed goto によるダイレクトスレッディング */
static void *table[] = { &&OP_IADD, &&OP_ILOAD, /* ... */ };
#define DISPATCH() goto *table[code[pc++]]
OP_IADD:  /* ... */  DISPATCH();
OP_ILOAD: /* ... */  DISPATCH();

中央の switch を1か所通る方式と違い、分岐元が命令ごとに分散します。すると CPU の分岐予測器は「命令 X の次は命令 Y が来やすい」という命令列のクセを学習でき、予測精度が上がります。switch 方式に対して 2 割前後の高速化が報告されることもあります。さらに進めると、ホットな経路を実行時に機械語へ変換する JIT に至り、ディスパッチそのものを消し去ります。

生成・検証・移植のしやすさ

性能ではスタック型が不利に見えますが、別の軸では明確な利点があります。

• コンパイラが書きやすい — 式は木構造であり、後行順（ポストオーダー）に辿るだけでスタック型バイトコードが素直に出力できます。レジスタ型はどの値をどのレジスタに割り当てるか（レジスタ割り当て）を決める必要があり、ここは計算量の観点でも厄介な最適化問題です。
• 検証が単純 — JVM は実行前にバイトコードのスタック整合性（各地点で型と深さが一致するか）を検証します。スタックという一本道の構造は、この抽象解釈による検証と相性が良いのです。
• 命令が短く密 — オペランドを持たないぶん、配布されるバイトコード列がコンパクトになります。

まとめ

スタック型 VM とレジスタ型 VM の違いは、オペランドを暗黙のスタックで運ぶか、命令に番号を埋めて明示するかという計算機モデルの差です。レジスタ型は同じ計算を少ない命令で表せるため、ディスパッチ回数と分岐予測ミスが減り、純インタプリタとしては速くなりやすい——これが Dalvik や Lua の設計判断の背景です。一方スタック型は、コンパイラ実装・バイトコード検証・移植性で優位に立ち、JVM や Wasm が選ぶ理由になっています。さらにダイレクトスレッディングや JIT を重ねれば、どちらのモデルでもディスパッチのコストは大きく削れます。「どちらが速いか」ではなく「何を単純にし、何を犠牲にするか」というトレードオフとして捉えるのが正確です。