什麼是HotSpot

沒錯，Java是解釋語言，但並不意味著它一定被解釋執行。早期
的虛擬機器確實一條一條指令解釋執行，但人們發現這樣效率太低，
不滿足各種要求，因此出現了許多其它虛擬機器，如JIT的虛擬機器。
HotSpot也是類似一種虛擬機器，自從SUN買下後，已經把它放入
JRE 1.3以及後續版本中。
 
採用HotSpot的Java虛擬機器，已經很難說Java是被虛擬機器解釋執行了，
原因是HotSpot實際上是把Java的bytecode編譯成Native code，
然後執行。
 
實際上在HotSpot虛擬機器中，有兩個技術是至關重要的，即動態編譯和
Profiling。HotSpot對bytecode的編譯，不是在程式執行前預先編譯的，
而是在程式執行過程中，動態編譯(compile during run-time)，英文稱
Dynamic compilation。其實Just In Time也就是這個意思。
 
HotSpot是如何動態編譯Javad的bytecode呢？它採用的是一種smart的辦法。
HotSpot裡有一個執行監視器，即Profile Monitor(不知國內如何翻譯Profile),
專門監視程式執行中，哪一部分運用頻度大， 哪些對效能影響至關重要。
當然Profile Monitor有一些演算法，這些演算法未必十全十美，但大體是能較好
獲得相關資訊的。對於那些對程式執行效率影響交大的程式碼，稱為熱點，
即hot spot，HotSpot會把這些部門動態地編譯成機器碼，Native code，
同時也對機器碼進行優化（類似C編譯器的一些優化），從而而提高執行效率。
而那些較少執行的Code，HotSpot虛擬機器就不再浪費時間把它們編譯。
 
總體來看，Java bytecode是以解釋方式被load到虛擬機器的。但虛擬機器的
分析器根據一段執行，獲知對程式效率影響最大的部分，然後通過動態
編譯，同時進行優化，編譯成機器碼，然後為接下來的執行加速。總的
來說，HotSpot對bytecode有三層處理：不編譯，編譯，編譯並優化。
至於程式哪部分不編譯，哪部分編譯，哪部分做何種優化，則由Profile
Monitor決定。
 
那麼為什麼Java採用動態編譯器而不是象C++這樣採用靜態編譯器呢？
虛擬機器提供的跨平臺執行條件固然是一方面，動態編譯器也在許多方面
比靜態編譯器優越。Profiling就是一個例子。靜態編譯器通常很難準確
預知程式執行過程中究竟什麼部分最需要優化。靜態編譯器雖然可以把Java
全部編譯成Native Code，但卻做不到動態編譯器那樣的優化。
 
另一個典型的例子，叫做Method inlining。我們知道無論是在C還是在
Java裡，函式呼叫都是很浪費系統時間的，因為有許多進棧出棧操作。
因此有一種優化辦法，就是把原來的函式呼叫，通過編譯器的編譯，改成
非函式呼叫，把函式程式碼直接嵌到呼叫出，變成順序執行。
 
但這一方法在Java/C++這樣的物件導向的語言的編譯器中，較難很好實現。
那些靜態編譯器，通常可以把private，static等函式進行Method inlining，
但由於這些物件導向的語言支援函式過載，支援動態聯編(不知道是不是這樣
翻譯，Overridden, dynamic binding),因此靜態編譯器並不知道究竟應該
把函式的哪個實現給inline了。
 
HotSpot的動態編譯，由於有對函式呼叫的監視，因此可以準確地知道一些環境
下，那些被過載和動態識別的函式可以如何被inline到呼叫者那裡去，因此
實際上對於一些Server應用來說，可以大幅度提高效率。
 
HotSpot實際上有兩個版本，一個是Server版，一個是Client版。但它們的結構
和本質都是一樣的，只是有些地方優化不一樣。
 
瞭解了這些，就知道，有時候Java的程式甚至能比C程式執行還快。