解析JVM和JIT診斷技術的用法
在任何給定的時刻，JVM進程包含一些可執行文件和一些使用JIT編譯的代碼，它們被動態鏈接到JVM中的MMI方法的封裝程序上。JIT編譯的本地機器代碼被放置到JVM本地數據內存段中，這樣就可以增加JVM進程的本地內存占用，并且MMI封裝程序被修改為指向編譯后的代碼。
JIT診斷
本節將介紹在問題發生時用來調試和診斷IBM JVM的JIT和MMI的技術。上一節簡要介紹了JIT，它是IBM JVM的一個基本部分。
在任何給定的時刻，JVM進程包含一些可執行文件和一些使用JIT編譯的代碼，它們被動態鏈接到JVM中的MMI方法的封裝程序上。JIT編譯的本地機器代碼被放置到JVM本地數據內存段中，這樣就可以增加JVM進程的本地內存占用，并且MMI封裝程序被修改為指向編譯后的代碼。
因此，JIT對于Java程序的執行流程會產生很大的影響。
◆在將程序從一個平臺上遷移到另外一個平臺上碰到的問題如下：
死鎖掛起
一直產生不正確的結果
結果不一致
不正常結束
無限循環
內存泄漏
對問題原因要考慮的第一件事情是JIT。
盡快在判斷問題原因時，確定JIT是否是問題的根源非常重要，這是由于3個原因：
◆問題可能是由于JIT在JVM中給定的活動角色而引起的。
◆JIT調試與其他類型的問題判斷技術有很大的不同。
◆JIT調試過程可能會非常耗費時間，而且非常復雜，通常需要高級的專門技術。#p#
確定是否是JIT問題
在某些情況下，從問題的特性可以很清楚地看出就是JIT的問題。例如，在JVM終止時帶有Javadump（在Linux上，Javadump的文件名的格式為javacore.YYYYMMDD.HHMMSS.PID.txt）或Linuxcore文件的情況下，從Javadump中的跟蹤信息或gdb對Java可執行文件和core文件的輸出信息中，可以很清楚地判斷出JIT就是產生問題的原因。在某些情況下，會直接顯示導致JVM進程死亡的信號是在libjitc.so中接收到的。在另外一些情況下，在JVM進程的代碼中，但是在該進程的已編譯代碼之外，會產生崩潰或掛起，這可以說明問題是由于JIT編譯的代碼產生的。
然而，在大部分情況下，并沒有清晰的跡象表明JIT是否是問題的源頭。因此，給定JIT的重要性后，在問題判斷過程中的第一個步驟應該是禁用JIT，除非這顯然不是一個與JIT相關的問題。即使在有跡象表明JIT就是問題的原因的情況下，最好也通過禁用JIT進行一下驗證，并重新運行一下禁用了JIT的程序。
要禁用JIT，首先請檢查一下當前環境變量JAVA_COMPILER的設置，然后將其設置為NONE。例如，對于BourneAgainShell（bash）或Kornshell（ksh），設置如下：exportJAVA_COMPILER=NONE
對于csh，設置如下：
- setenvJAVA_COMPILERNONE
另外一種禁用JIT的方法是向java命令傳遞-D參數，將java.compiler設置為NONE，從而覆蓋默認的環境變量置
- java-Djava.compiler=NONE<myapp>
JIT默認是被啟用的。要驗證JIT是否被啟用了，可以使用java命令的-version選項：java-version
如果沒有啟用JIT，就會顯示一個包含如下內容的消息：
- JITdisabled
如果啟用了JIT，就會顯示一個包含如下內容的消息：
- JITenabled:jitc
如果指定了JAVA_COMPILER=""或-Djava.compiler=""，那就禁用了JIT。如果JAVA_COMPILER沒有設置，如下：
- unsetJAVA_COMPILER
那么JIT編譯器就啟用了。
再次運行一下程序，看一下禁用JIT之后問題是否重現。如果問題可以重現，那么這就不是一個與JIT有關的問題。如果在禁用JIT之后問題就不存在了，那么這就可能是一個與JIT有關的問題。在禁用JIT之后問題就不再出現的現象并不意味著JIT編譯器就是問題的原因。例如，高度線程化且時間相關的程序中的方法在編譯后和解釋時的運行速度可能會不同，因此Java代碼中的邏輯錯誤只會在編譯代碼之后才會出現。
要啟用JIT，請將JAVA_COMPILER設置為jitc，或者使用下面的命令行來切換JIT編譯器：
- java-Djava.compiler=jitc<myapp>
或者取消JAVA_COMPILER環境變量的設置，或者從傳遞給java命令的選項中刪除-Djava.compiler選項。
【編輯推薦】
- Netbeans中設置JVM參數
- JVM內存回收問題處理方法
- 揭露MyEclipse JVM內存不足的內幕
- 專家指導 如何進行JVM參數配置
- 巧解IBM JVM for Linux onPOWER性能調優
