[深入理解Java虛擬機器]第八章 位元組碼執行引擎-基於棧的位元組碼解釋執行引擎

許多Java虛擬機器的執行引擎在執行Java程式碼的時候都有解釋執行(通過直譯器執行)和編譯執行(通過即時編譯器產生原生程式碼執行)兩種選擇,在本章中,我們先來探討一下在解釋執行時,虛擬機器執行引擎是如何工作的。

解釋執行

Java語言經常被人們定位為“解釋執行”的語言,在Java初生的JDK 1.0時代 ,這種定義還算是比較準確的,但當主流的虛擬機器中都包含了即時編譯器後,Class檔案中的程式碼到底會被解釋執行還是編譯執行,就成了只有虛擬機器自己才能準確判斷的事情。再後來 ,Java也發展出了可以直接生成原生程式碼的編譯器[如GCJ」(GNU Compiler for the Java )],而C/C++語言也出現了通過直譯器執行的版本(如CINT) ,這時候再籠統地說“解釋執行”,對於整個 Java語言來說就成了幾乎是沒有意義的概念,只有確定了談論物件是某種具體的Java實現版本和執行引擎執行模式時,談解釋執行還是編譯執行才會比較確切。

不論是解釋還是編譯,也不論是物理機還是虛擬機器,對於應用程式,機器都不可能如人那樣閱讀、理解 ,然後就獲得了執行能力。大部分的程式程式碼到物理機的目的碼或虛擬機器能執行的指令集之前,都需要經過圖8-4中的各個步驟。如果讀者對編譯原理的相關課程還有印象的話,很容易就會發現圖8-4中下面那條分支,就是傳統編譯原理中程式程式碼到目標機器程式碼的生成過程,而中間的那條分支,自然就是解釋執行的過程。

如今,基於物理機、Java虛擬機器,或者非Java的其他高階語言虛擬機器(HLLVM )的語 言 ,大多都會遵循這種基於現代經典編譯原理的思路,在執行前先對程式原始碼進行詞法分析和語法分析處理,把原始碼轉化為抽象語法樹( Abstract Syntax Tree,AST)。對於一門具體語言的實現來說,詞法分析、語法分析以至後面的優化器和目的碼生成器都可以選擇獨立於執行引擎,形成一個完整意義的編譯器去實現,這類代表是C/C++語言。也可以選擇把其中一部分步驟(如生成抽象語法樹之前的步驟)實現為一個半獨立的編譯器,這類代表是Java 語言。又或者把這些步驟和執行引擎全部集中封裝在一個封閉的黑匣子之中,如大多數的JavaScript執行器。

圖8-4 編譯過程

Java語言中 ,Javac編譯器完成了程式程式碼經過詞法分析、語法分析到抽象語法樹,再遍歷語法樹生成線性的位元組碼指令流的過程。因為這一部分動作是在Java虛擬機器之外進行的, 而直譯器在虛擬機器的內部,所以Java程式的編譯就是半獨立的實現。

基於棧的指令集與基於暫存器的指令集

Java編譯器輸出的指令流，基本上是一種基於棧的指令集架構( Instruction Set Architecture,ISA ) , 指令流中的指令大部分都是零地址指令,它們包賴運算元棧進行工作。與之相對的另外一套常用的指令集架構是基於暫存器的指令集,最典型的就是x86的二地址指令集 ,說得通俗一些,就是現在我們主流PC機中直接支援的指令集架構,這些指令依賴暫存器進行工作。那麼 ,基於棧的指令集與基於暫存器的指令集這兩者之間有什麼不同呢?

舉個最簡單的例子,分別使用這兩種指令集計算“ 1+1”的結果,基於棧的指令集會是這樣子的:

iconst_1
iconst_1
iadd
istore_0

兩條iconst_1指令連續把兩個常量1壓入棧後,iadd指令把棧頂的兩個值出棧、相 加 ,然後把結果放回棧頂 ,最後istore_0把棧頂的值放到區域性變數表的第0個Slot中。

如果基於暫存器,那程式可能會是這個樣子:

mov eax ,1 
add eax ,1

mov指令把EAX暫存器的值設為1 ,然後add指令再把這個值加1 ,結果就儲存在EAX暫存器裡面。

瞭解了基於棧的指令集與基於暫存器的指令集的區別後,讀者可能會有進一步的疑問, 這兩套指令集誰更好一些呢?

應該這麼說,既然兩套指令集會同時並存和發展,那肯定是各有優勢的,如果有一套指令集全面優於另外一套的話,就不會存在選擇的問題了。

基於棧的指令集主要的優點就是可移植,暫存器由硬體直接提供,程式直接依賴這些硬體暫存器則不可避免地要受到硬體的約束。例如 ,現在32位80x86體系的處理器中提供了8 個32位的暫存器,而ARM體系的CPU ( 在當前的手機、PDA中相當流行的一種處理器)則提供了16個32位的通用暫存器。如果使用棧架構的指令集,使用者程式不會直接使用這些暫存器 ,就可以由虛擬機器實現來自行決定把一些訪問最頻繁的資料(程式計數器、棧頂快取等) 放到暫存器中以獲取儘量好的效能,這樣實現起來也更加簡單一些。棧架構的指令集還有一 些其他的優點,如程式碼相對更加緊湊(位元組碼中每個位元組就對應一條指令,而多地址指令集中還需要存放引數)、編譯器實現更加簡單(不需要考慮空間分配的問題,所需空間都在棧上操作 ) 等。

棧架構指令集的主要缺點是執行速度相對來說會稍慢一些。所有主流物理機的指令集都是暫存器架構也從側面印證了這一點。

雖然棧架構指令集的程式碼非常緊湊,但是完成相同功能所需的指令數量一般會比暫存器架構多,因為出棧、入棧操作本身就產生了相當多的指令數量。更重要的是 ,棧實現在記憶體之中 ,頻繁的棧訪問也就意味著頻繁的記憶體訪問,相對於處理器來說,記憶體始終是執行速度的瓶頸。儘管虛擬機器可以採取棧頂快取的手段,把最常用的操作對映到暫存器中避免直接記憶體訪問 ,但這也只能是優化措施而不是解決本質問題的方法。 由於指令數量和記憶體訪問的原因 ,所以導致了棧架構指令集的執行速度會相對較慢。

注：
部分位元組碼指令會帶有引數,而純粹基於棧的指令集架構中應當全部都是零地址指令,也就是都不存在顯式的引數。Java這樣實現主要是考慮了程式碼的可校驗性。

這裡說的是物理機器上的暫存器,也有基於暫存器的虛擬機器,如Google Android平臺的 Dalvik VM。即使是基於暫存器的虛擬機器,也希望把虛擬機器暫存器儘量對映到物理暫存器上以獲取儘可能高的效能。

基於棧的直譯器執行過程

初步的理論知識已經講解過了,本節準備了一段Java程式碼 ,看看在虛擬機器中實際是如何執行的。前面曾經舉過一個計算“ 1+1”的例子,這樣的算術題目顯然太過簡單了,筆者準備了四則運算的例子,請看程式碼清單8-16。

從Java語言的角度來看,這段程式碼沒有任何解釋的必要,可以直接使用javap命令看看它的位元組碼指令,如程式碼清單8-17所示。

javap提示這段程式碼需要深度為2的運算元棧和4個Slot的區域性變數空間,筆者根據這些資訊畫了圖8-5〜圖8-11共7張圖,用它們來描述程式碼清單8-17執行過程中的程式碼、運算元棧和區域性變數表的變化情況。

上面的執行過程僅僅是一種概念模型,虛擬機器最終會對執行過程做一些優化來提高效能 ,實際的運作過程不一定完全符合概念模型的描述……更準確地說,實際情況會和上面描述的概念模型差距非常大,這種差距產生的原因是虛擬機器中解析器和即時編譯器都會對輸入的位元組碼進行優化,例如 ,在HotSpot虛擬機器中,有很多以“fast_”開頭的非標準位元組碼指令用於合併、替換輸入的位元組碼以提升解釋執行效能,而即時編譯的優化手段更加花樣繁多。

不過 ,我們從這段程式的執行中也可以看出棧結構指令集的一般執行過程,整個運算過程的中間變數都以運算元棧的出棧、入棧為資訊交換途徑,符合我們在前面分析的特點。