Java -HotSpot -Client -Server 介紹

文章目錄

• 寫在前面
• Java HotSpot VM 的架構

Java HotSpotTM VM 簡介

　

寫在前面

JavaTM 技術已經逐漸變程式軟體程式開發的主流了，隨著各界對於 Java 的採納，這項技術在各個領域都是以爆炸性的速度在成長，不管是從信用卡到大型主機上，或是從網頁上的 applet 到大型的商業應用技術。在過去，雖然 JavaTM 技術提供了一個不但容易移植，而且又安全的開發環境，但也由於容易移植的這個特性，造成了程式在執行的時候效能的低落。不過目前的技術發展進步，所以在效能上的低落這項缺點，也逐漸的改進了。

Java HotSpotTM 虛擬機器（VM）是 Java 2 Platform, Standard Edition（J2SETM）軟體的一項核心技術，並且廣泛的被一些「整合開發環境（IDEs）」還有「Application Server」所使用，包括有 ForteTM for JavaTM、Borland JBuilder、WebGain VisualCafe、Oracle JDeveloper、Metrowerks CodeWarrior、NetBeansTM Open Source Project、BEA Systems（WebLogic Server）還有 iPlanet（iPlanetTM Application Server）等等。與之前的版本比較起來，Java HotSpotTM 虛擬機器在效能方面加強了許多，特別是在 garbage collection 還有 thread 的處理方面。此外，Java HotSpotTM 虛擬機器可以透過「client」或是「server」這兩個字來決定是要使用 Java HotSpot Client VM 或是 Java HotSpot Server VM 來將應用程式作最佳效能的處理。

在 Java 2 SDK, Standard Edition v1.3.1 當中，Java HotSpot VM 包含了許許多多新的效能提升技術，最主要增加的地方有以下幾點：

1. 在執行時間（Runtime）方面
   • 當致命的錯誤在虛擬機器當中發生，不論是在 VM 當中引起的，或是由使用者使用的 native code，都會有較佳的回報功能。
   • Java Virtual Machine Debugger Interface（JVMDI）和 Java Virtual Machine Profiler Interface（JVMPT）的特性現在完全支援了。
   • 在這個版本的 VM 是由一致性的原始碼所建構出來的，方便移植到所有支援的平台。

   　

2. 在 Garbage Collection 方面
   • Garbage collector 現在已經可以完全使用 32-bit 系統中的位址空間了，這表示可以存取 4g 大小的 heap 了。不過在這邊要注意的是，並不是所有的作業環境都支援這麼大的 heap，SolarisTM 的話有支援。
   • Garbage collector 已經調整用來支援大型應用程式和 UltraSPARCTM III 平台。

   　

3. 在 Java HotSpot Client VM 方面
   • 確保 VM 的特性可以橫跨所支援的平台。

   　

4. 在 Java HotSpot Server VM 最佳化方面
   • Java 在對於每個陣列的存取，都會去檢查有無超過邊界。但若是編譯器已經確定陣列存取是在範圍之內的話，那麼就可以把這項檢查消除掉。
   • Server VM 現在新增加了 loop unrolling 這項特性，可以用來加快迴圈的執行。
   • 對於 UltraSPARC III 的最佳化增加了 instruction scheduling 的功能。
   • 對 Java reflection API 做物件導向的最佳化處理。

　

Java HotSpot VM 的架構

對於 Java HotSpot VM 它的架構，在這邊我們分成下面幾個方向來介紹說明：

1. 記憶體模型（memory model）方面

   在以往先前的 Java 虛擬機器當中，是使用間接處理的方式來處理物件之間的參考。這使的我們在 garbage collection 的時候要 relocate 物件會變的比較容易，不過，這卻也變成是效能的瓶頸所在。因為當我們要存取所實作出來物件當中的變數的話，要經過兩層的步驟。

   新一代的 Java HotSpot VM 對於物件之間的參考，就直接實作成了指標，所以我們可以就像是用 C 的存取速度來存取我們實作出來的變數。而 garbage collector 就是當物件在記憶體當中被 relocate 的時候，我們為了要找出或是更新在同一塊區域當中，所有同樣參考到這個物件所設計出來的。

   除此之外，新的 Java HotSpot VM 也使用了有兩個機器字元的檔頭（machine-word object header）來取代之前所採用的三個，這表示我們對於每個應用程式可以節省掉將進 8% 的 heap大小。在這邊，第一個 header 包含了例如 hash code 或是 garbage collector 狀態的訊息，第二個 header 則是表示參考到哪個物件類別，只有當我們使用陣列的時候才會出現第三個 header 欄位－是用來表示陣列大小的。

   　

2. Garbage Collection 方面

   對於程式設計者來說，使用 Java 作為其程式開發語言其中有個重要的因素是，它提供了自動的記憶體管理（或稱之為 garbage collection）。在傳統的程式語言上，我們要動態的配置記憶體空間的話，需要由我們自己設定。但在實際上，這也容易造成程式經常記憶體使用不足，或是易造成 crash。

   當新一代的 garbage collector 在確定並且證明某個物件已經不會在這個程式當中被使用到了，那麼，它會在背景自動處理釋放這些已經沒有在使用的物件所佔的記憶體。

   在傳統上，garbage collection 經常會帶給大家這是個沒有效率的處理，或是程式效能低落的瓶頸所在。但是在新一代的 garbage collection 技術當中，會自動的考慮到整體的效能，並且對於記憶體釋放有更好的處理。

   　

3. Thread Synchronization 方面

   在過去 Java 在同步化的實作上，會相當的沒有效率是因為跟其他在 Java 當中的操作運算有關，同時也是效能的瓶頸所在的主要原因之一。新一代的 Java HotSpot VM 在 thread 的實作上面有重大的突破，包含提高同步效能這個項目。此外，Java HotSpot VM 對於 thread 處理提供了線性執行還有有加速的能力，並且設計能夠在擁有大量共用記憶體的多處理器伺服器上能夠立刻變化擴充加速處理的能力。

　

　

上次小弟為大家簡單介紹了 Java 2 SDK, Standard Edition v1.3.1 當中，Java HotSpot VM 的一些新的特性和它的架構，這次小弟將跟大家繼續介紹 Java HotSpot VM 和其編譯器（compiler）部份。

相信在大家安裝完 Java 2 SDK, Standard Edition v1.3.1 之後，若您的作業系統是 Windows 的話，會在 C:/安裝 jdk 的目錄/jre/bin 下發現有三個目錄，分別為「classic」、「hotspot」和「server」這三個。若是您在提示符號下執行 java.exe 程式的話，後面接上 -version 的參數，則可分別看到類似下面的訊息：

C:/jdk/jre/bin>java -version java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode) C:/jdk/jre/bin>

C:/jdk/jre/bin>java -server -version java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Server VM (build 1.3.1-b24, mixed mode) C:/jdk/jre/bin>

C:/jdk/jre/bin>java -classic -version java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Classic VM (build 1.3.1-b24, native threads, nojit) C:/jdk/jre/bin>

另外，若是使用 -X 的參數的話，也可以看到明顯的不同：

C:/>java -server -X -Xmixed mixed mode execution (default) -Xint interpreted mode execution only -Xbootclasspath:<directories and zip/jar files separated by ;> set search path for bootstrap classes and resources -Xbootclasspath/a:<directories and zip/jar files separated by ;> append to end of bootstrap class path -Xbootclasspath/p:<directories and zip/jar files separated by ;> prepend in front of bootstrap class path -Xnoclassgc disable class garbage collection -Xincgc enable incremental garbage collection -Xbatch disable background compilation -Xms<size> set initial Java heap size -Xmx<size> set maximum Java heap size -Xss<size> set java thread stack size -Xprof output cpu profiling data -Xrunhprof[:help]|[:<option>=<value>, ...] perform JVMPI heap, cpu, or monitor profiling -Xdebug enable remote debugging -Xfuture enable strictest checks, anticipating future default -Xrs reduce use of OS signals by Java/VM (see documentation) The -X options are non-standard and subject to change without notice. C:/>

C:/>java -classic -X -Xbootclasspath:<directories and zip/jar files separated by ;> set search path for bootstrap classes and resources -Xbootclasspath/a:<directories and zip/jar files separated by ;> append to end of bootstrap class path -Xbootclasspath/p:<directories and zip/jar files separated by ;> prepend in front of bootstrap class path -Xnoclassgc disable class garbage collection -Xms<size> set initial Java heap size -Xmx<size> set maximum Java heap size -Xrs reduce the use of OS signals -Xcheck:jni perform additional checks for JNI functions -Xcheck:nabounds perform additional checks for JNI array operations -Xrunhprof[:help]|[:<option>=<value>, ...] perform heap, cpu, or monitor profiling -Xdebug enable remote debugging -Xfuture enable strictest checks, anticipating future default The -X options are non-standard and subject to change without notice. C:>

　

從上面的訊息我們可以看到，除了傳統的 Classic VM 之外，Java HotSpot VM 還分成了 Client VM 和 Server VM。其實，不管是 client 還是 server 的 VM，都共用了 Java HotSpot 執行環境的基本程式，但是它們使用了不同的編譯器來讓 client 或是 server 端執行環境的效能特效能夠彰顯出來。對於 server VM 來說，它會特別將程式的操作速度微調至最好的部份，所以用來執行 server 端的應用程式的話，可以擁有較快的啟動時間還有當應用程式在執行的時候，會佔據較少的記憶體空間。另外，對於 client VM 來說，它主要增進的效能是在於 client 端的應用程式，或是 applet 部份。Java HotSpot Client VM 會特別調整應用程式的啟動速度和記憶體使用空間，讓它對於我們在 client 的環境可以「非常速配」。一班來說，若是  client 端系統有 GUI 介面的話，會有比較好的成效。

在編譯器方面的話，client VM 的編譯器並不會去執行類似像是 server VM 那樣複雜的最佳化技術，所以它會花較少的時間在分析和編譯 code 上面。從另一個觀點來看，就是它在啟動時間會增快，並且耗費較少的記憶體空間。另外，client VM 在編譯的過程可以分為兩個階段來描述，第一個部份是各平台獨立的分析 bytecode，第二部份的話，則是根據各個平台不同來產生機器碼。相對的在 server VM 方面，它使用了更強的「具有可調變能力的編譯器」，這比傳統的靜態的編譯器具有更多的優點與特性。

　

結語

Java HotSpot VM 在程式方面做了更強的最佳化處理，另外，在 garbage collection 還有 thread 同步方面也做了相當大的改進。除此之外，Java HotSpot VM 對於 client 和 server 端的應用程式，分別提供了不同的執行環境，使的應用程式在執行的時候，可以獲得最好的效果。若是大家對於 Java HotSpot VM 有興趣的話，可以到 http://java.sun.com/products/hotspot/index.html 這邊獲得更多的相關資料。