hakorune/docs/research/paper-12-vm-stepping-stone/key-insights.md

Key Insights: VM as a Stepping Stone

核心的な発見

1. 偶然から生まれた方法論

当初の計画（2024年8月）

MIR → VM   (インタープリタ実行用)
MIR → LLVM (ネイティブ実行用)

並列に実装する予定だった。

実際の経緯

MIR → VM → LLVM

実装の都合でVM経由にしたところ、予想外の利点が判明。

2. VM層の5つの役割

2.1 Living Specification（生きた仕様書）

// VMで確立されたセマンティクス
match instr {
    CallPlugin { type_id: 11, method_id: 3, args: [1, 42] }
    => MapBox.set(1, 42) の動作が確定
}

2.2 Validation Layer（検証層）

• MIR生成が正しいか → VMで実行して確認
• プラグインFFIが正しいか → VMで動作確認
• 型システムが健全か → VMで実行時チェック

2.3 Debug Reference（デバッグ基準）

問題: LLVM実行で "Result: 0" （期待値: "Result: 42"）
診断: VM実行 → "Result: 42" → LLVMの実装バグと特定
時間: 30分で解決（argc-1の問題）

2.4 Pattern Establisher（パターン確立）

// VM実装で確立したパターン
let tlv_args = encode_tlv_header(argc) + encode_args(args);
call_plugin(type_id, method_id, tlv_args);

// LLVM実装でそのまま再利用
builder.call(nyash_plugin_invoke3_tagged_i64, [type_id, method_id, argc, ...]);

2.5 Incremental Complexity（段階的複雑性）

1. 単純な整数演算 → VM実装 → LLVM移植
2. プラグイン呼び出し → VM実装 → LLVM移植
3. 可変長引数 → VM実装 → LLVM移植

3. 定量的効果

開発速度

• MIR設計: 1ヶ月（2024年8月）
• VM実装: 2ヶ月（2024年9-10月）
• LLVM実装: 3ヶ月（2024年11月-2025年1月）
• 合計: 6ヶ月でネイティブコンパイラ完成

コード再利用

src/runtime/plugin_loader_v2.rs - VM/LLVM共通
src/runtime/plugin_ffi_common.rs - VM/LLVM共通
crates/nyrt/ - 完全共有
→ 約80%のランタイムコードを共有

デバッグ効率

• VInvokeバグ: 30分で解決（VM比較）
• 推定: 従来手法なら2-3時間

4. 一般化可能な条件

この手法が有効な言語の特徴

1. 統一的な実行モデル: Everything is Box のような統一概念
2. プラグインシステム: FFI/ABIが重要な役割
3. 段階的な機能追加: 基本機能から複雑な機能へ

適用が難しい場合

1. VMとネイティブで根本的に異なる実行モデル
2. 極度に最適化されたネイティブコードが必要
3. VM実装のオーバーヘッドが許容できない

5. 理論的含意

ソフトウェア工学的視点

• Iterative Refinement: VM→LLVMは自然な洗練プロセス
• Separation of Concerns: 正しさ（VM）と性能（LLVM）の分離
• Fail Fast: 問題をVM段階で早期発見

プログラミング言語理論的視点

• Semantic Preservation: VMセマンティクスの保存性
• Bisimulation: VM実行とLLVM実行の等価性証明が容易
• Gradual Verification: 段階的な正しさの確認

6. 今後の研究課題

1. 自動化: VM実装からLLVM実装への自動変換
2. 形式的証明: VM-LLVM等価性の形式的証明
3. 最適化: VM実行情報を使ったLLVM最適化

まとめ

「VM as a Stepping Stone」パターンは、偶然の発見から生まれた実用的な言語実装手法である。特に、プラグインシステムを持つ言語や、統一的な実行モデルを持つ言語において、開発効率とコード品質の両面で大きな利点をもたらす。