將虛擬機設計與主要編程語言相匹配

Question

作爲一個側面項目的背景，我一直在閱讀有關不同的虛擬機設計，JVM當然獲得最多的新聞。我也看了BEAM（Erlang），GHC的RTS（一種但不是VM）和一些JavaScript實現。 Python也有一個我知道存在的字節碼解釋器，但沒有多讀。

我沒有找到的是的一個很好的解釋，爲什麼特定的虛擬機設計選擇是針對特定語言進行的。我對能夠適應併發和/或非常動態（Ruby，JavaScript，Lisp）語言的設計選擇特別感興趣。

---

編輯：在迴應評論請求特異性下面是一個例子。 JVM使用堆棧機器而不是註冊機器，這在Java引入時非常具有爭議性。事實證明，設計JVM的工程師已經完成了想要的平臺可移植性，並且將堆棧機器轉換回寄存器機器更容易且更高效，然後克服虛擬太多或太少寄存器的阻抗不匹配。

下面是另一個例子：對於Haskell，要看的論文是Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine。這與我瞭解的任何其他類型的虛擬機非常不同。事實上，GHC（Haskell的首要實現）並不是直播，而是作爲編譯的中間步驟。 Peyton-Jones列出了不少於8個不起作用的其他虛擬機。我想了解爲什麼有些虛擬機在其他失敗的情況下取得成功。

Answer 1

我會用不同的方式回答你的問題：什麼是虛擬機？虛擬機只是一種低級語言的「解釋器」規範，而不是源語言。在這裏，我使用「解釋器」這個詞的黑盒含義。我不在乎虛擬機如何實現（作爲字節碼整合器，JIT編譯器，不管）。當這樣表達時，從設計的角度來看，虛擬機並不是有趣的東西，它是低級語言。

理想的VM語言將做兩件事。其一，它將使編譯源語言變得容易。而且它還可以很容易在目標平臺上解釋（解釋器可以非常天真地實現，或者可以是一些非常複雜的JIT，如Hotspot或V8）。

很明顯，這兩種理想屬性之間存在着緊張關係，但它們通過所有可能的虛擬機的設計空間或多或少地形成了兩條終點。 （或者，也許比線更復雜的形狀，因爲這不是一個平坦的歐幾里德空間，但你明白了）。如果你將虛擬機語言建立在該行之外，那麼它將不會非常有用。這就限制了虛擬機的設計：把它放在理想的路線上。

該行也是爲什麼高級別VM傾向於非常特定語言，而低級別VM更多語言不可知，但不提供許多服務。高級虛擬機本質上接近源語言，這使得它遠離其他不同的源語言。低級虛擬機的本質是接近目標平臺，因此接近許多語言的理想線路的平臺端，但是低級虛擬機也離理想線的「易於編譯」結束還很遠。大多數源語言。

現在，更廣泛地說，從概念上講，任何編譯器都可以看作是從源語言到中間形式的一系列轉換，它們本身可以被看作是虛擬機的語言。中間語言的VM可能永遠不會構建，但它們可能是。編譯器最終會發出最終的表單。最終形式本身就是虛擬機的語言。我們可以稱該虛擬機爲「JVM」，「V8」......或者我們可以稱該虛擬機爲「x86」，「ARM」等。

希望有幫助。

Answer 2

我覺得這本書很有幫助。它討論了你所提到的許多問題。 （請注意，我與亞馬遜沒有任何關係，我也不提倡亞馬遜;只是最容易鏈接的地方）。

http://www.amazon.com/dp/1852339691/

Answer 3

一個導出虛擬機的技術是剛剛下井編譯鏈，將您的源語言到越來越低級別的中間語言。一旦你發現一個足夠低的語言適合一個平面表示（即，可以序列化爲一系列「指令」），這幾乎是你的虛擬機。而且您的VM解釋器或JIT編譯器只會從您爲序列化選擇的位置繼續您的轉換鏈。一些序列化技術非常普遍 - 例如，對錶達式樹使用僞堆棧表示（就像在.NET CLR中，它根本不是一個「真正的」堆棧機器）。否則，您可能希望使用SSA格式進行序列化，如在LLVM中，或者簡單地使用具有無限數量寄存器的3地址VM（如在Dalvik中）。這並不重要，因爲它只是一個序列化，稍後它將被反序列化以繼續使用正常的編譯方式。

如果您打算立即解讀您的VM代碼而不是編譯它，這有些不同。目前尚未達成共識，哪種虛擬機更適合解釋。堆棧 - （或者我敢說，Forth-）基於虛擬機和基於寄存器已被證明是有效的。