上一節我們講了早期的優化（編譯器），這一節我們看一看晚期的優化（執行期的優化）

1、概述

java程式最初是通過直譯器進行解釋執行的，當虛擬機發現某個方法或程式碼塊的執行特別頻繁，就會把這些程式碼認定為“熱點程式碼”，為了提高熱點程式碼的執行效率，在執行時，虛擬機器會把這些程式碼編譯成與本地平臺相關的機器碼，並進行各種層次的優化，完成這個任務的編譯器稱為即時編譯器（Just in Time Compiler JIT）.

即時編譯器並不是虛擬機器必需的部分，java虛擬機器規範中並沒有規定java虛擬機器內必須要有即時編譯器，更沒有限定或指導即時編譯器應該如何去實現。但是即時即時編譯器是虛擬機器中最能體現技術水平的部分。

2 HotSpot虛擬機器內的即時編譯器

幾個問題

• 為何HotSpot虛擬機器要使用直譯器與編譯器並存的架構？
• 為何HotSpot虛擬機器要實現兩個不同的即時編譯器？
• 程式何時使用直譯器執行？何時使用編譯器執行？
• 哪些程式程式碼會被編譯為原生代碼？如何編譯為原生代碼？
• 如何從外部觀察即時編譯器的編譯過程和編譯結果？

2.1 直譯器與編譯器

儘管不是所有java虛擬機器都採用直譯器與編譯器並存的架構，但許多主流的虛擬機器如HotSpot，J9，都同時包含直譯器與編譯器，直譯器與編譯器兩者各有優勢：

優勢一：當程式需要迅速啟動和執行的時候，直譯器可以首先發揮作用，省去編譯的時間，立即執行。

優勢二：當程式執行後，隨著時間的推移，編譯器逐漸發揮作用，把越來越多的程式碼編譯成原生代碼後，可以獲取更高的執行效率。

HotSpot虛擬機器中內建了兩個即時編譯器，分別稱為Client Compiler和Server Compiler，或者簡稱為C1編譯器–Client 和C2編譯器– Server（也叫Opto編譯器）。HotSpot虛擬機器會根據自身版本與宿主機器的硬體效能自動選擇執行模式，使用者也可以使用“-client”或“-server”引數去強制指定虛擬機器執行在Client模式或Server模式。
直譯器與編譯器搭配使用的方式在虛擬機器中稱為“混合模式”（Mixed Mode），使用者可以使用引數“-Xint”強制虛擬機器運行於“解釋模式”（Interpreted Mode），這時編譯器完全不介入工作，全部程式碼都使用解釋方式執行。另外，也可以使用引數“-Xcomp”強制虛擬機器運行於“編譯模式”（Compiled Mode），這時將優先採用編譯方式執行程式，但是直譯器仍然要在編譯無法進行的情況下介入執行過程。

即時編譯器編譯原生代碼需要佔用程式執行時間，要編譯出優化程度更高的程式碼，所花費的時間可能更長；而且想要編譯出優化程度更高的程式碼，直譯器可能還要替編譯器收集效能監控資訊，這對解釋執行的速度也有影響。 為了在程式啟動響應速度與執行效率之間達到最佳平衡，HotSpot虛擬機器還會逐漸啟用分層編譯（Tiered Compilation）的策略。

• 第0層，程式解釋執行，直譯器不開啟效能監控功能（Profiling），可觸發第1層編譯。
• 第1層，也稱為C1編譯，將位元組碼編譯為原生代碼，進行簡單、可靠的優化，如有必要將加入效能監控的邏輯。
• 第2層（或2層以上），也稱為C2編譯，也是將位元組碼編譯為原生代碼，但是會啟用一些編譯耗時較長的優化，甚至會根據效能監控資訊進行一些不可靠的激進優化。

實施分層編譯後，Client Compiler和Server Compiler將會同時工作，許多程式碼都可能會被多次編譯，用Client Compiler獲取更高的編譯速度，用Server Compiler來獲取更好的編譯質量，在解釋執行的時候也無須再承擔收集效能監控資訊的任務。

2.2  編譯物件與觸發條件

“熱點程式碼”有兩類，

• 被多次呼叫的方法 – 這是由方法呼叫觸發的編譯，因此編譯器理會以整個方法作為編譯物件，這種編譯也是虛擬機器中標準的JIT編譯方式。
• 被多次執行的迴圈體 – 儘管編譯動作是由迴圈體所觸發的，但編譯器依然會以整個方法（而不是單獨的迴圈體）作為編譯物件。這種編譯方式因為編譯發生在方法執行過程之中，因此形象地稱之為棧上替換（On Stack Replacement，簡稱為OSR編譯，即方法棧幀還在棧上，方法就被替換了）。

判斷一段程式碼是不是熱點程式碼，是不是需要觸發即時編譯，這樣的行為稱為熱點探測（Hot Spot Detection）；熱點探測判定方式有兩種

• 基於取樣的熱點探測（Sample Based Hot Spot Detection） – 虛擬機器會週期性地檢查各個執行緒的棧頂，如果發現某個（或某些）方法經常出現在棧頂，那這個方法就是“熱點方法”。 優點：實現簡單、 高效，還可以很容易地獲取方法呼叫關係； 缺點：缺點是很難精確地確認一個方法的熱度，容易因為受到執行緒阻塞或別的外界因素的影響而擾亂熱點探測
• 基於計數器的熱點探測（Counter Based Hot Spot Detection） – 虛擬機器會為每個方法（甚至是程式碼塊）建立計數器，統計方法的執行次數，如果執行次數超過一定的閾值就認為它是“熱點方法”。缺點：實現起來麻煩，不能直接獲取到方法的呼叫關係。優點：統計結果相對來說更加精確和嚴謹。

HotSpot虛擬機器中使用的是基於計數器的熱點探測方法，因此它為每個方法準備了兩類計數器：方法呼叫計數器（Invocation Counter）和回邊計數器（Back EdgeCounter）。確定虛擬機器執行引數的前提下，這兩個計數器都有一個確定的閾值，當計數器超過閾值溢位了，就會觸發JIT編譯。

• 方法呼叫計數器 – 統計方法被呼叫的次數，預設閾值在Client模式下是1500次，在Server模式下是10 000次，這個閾值可以通過虛擬機器引數-XX：CompileThreshold來設定。當一個方法被呼叫時，會先檢查該方法是否存在被JIT編譯過的版本，如果存在，則優先使用編譯後的原生代碼來執行。如果不存在已被編譯過的版本，則將此方法的呼叫計數器值加1，然後判斷方法呼叫計數器與回邊計數器值之和是否超過方法呼叫計數器的閾值。如果已超過閾值，那麼將會向即時編譯器提交一個該方法的程式碼編譯請求。如果不做任何設定，執行引擎並不會同步等待編譯請求完成，而是繼續進入直譯器按照解釋方式執行位元組碼，直到提交的請求被編譯器編譯完成。當編譯工作完成之後，這個方法的呼叫入口地址就會被系統自動改寫成新的，下一次呼叫該方法時就會使用已編譯的版本。

• 如果不做任何設定，方法呼叫計數器統計的並不是方法被呼叫的絕對次數，而是一個相對的執行頻率，即一段時間之內方法被呼叫的次數。當超過一定的時間限度，如果方法的呼叫次數仍然不足以讓它提交給即時編譯器編譯，那這個方法的呼叫計數器就會被減少一半，這個過程稱為方法呼叫計數器熱度的衰減（Counter Decay），而這段時間就稱為此方法統計的半衰週期（Counter Half Life Time）。
• 可以使用虛擬機器引數-XX：-UseCounterDecay來關閉熱度衰減，讓方法計數器統計方法呼叫的絕對次數，這樣，只要系統執行時間足夠長，絕大部分方法都會被編譯成原生代碼。另外，可以使用-XX：CounterHalfLifeTime引數設定半衰週期的時間，單位是秒。
• 回邊計數器，它的作用是統計一個方法中迴圈體程式碼執行的次數，在位元組碼中遇到控制流向後跳轉的指令稱為“回邊”（Back Edge）。 顯然，建立回邊計數器統計的目的就是為了觸發OSR編譯。可以通過-XX：OnStackReplacePercentage來間接調整回邊計數器的閾值。

• 回邊計數器沒有計數熱度衰減的過程，因此這個計數器統計的就是該方法迴圈執行的絕對次數。 當計數器溢位的時候，它還會把方法計數器的值也調整到溢位狀態，這樣下次再進入該方法的時候就會執行標準編譯過程。

2.3 編譯過程

預設設定下，無論是方法呼叫產生的即時編譯請求，還是OSR編譯請求，虛擬機器在程式碼編譯器還未完成之前，都仍然將按照解釋方式繼續執行，而編譯動作則在後臺的編譯執行緒中進行。使用者可以通過引數-XX：-BackgroundCompilation來禁止後臺編譯，在禁止後臺編譯後，一旦達到JIT的編譯條件，執行執行緒向虛擬機器提交編譯請求後將會一直等待，直到編譯過程完成後再開始執行編譯器輸出的原生代碼。Server Compiler和Client Compiler兩個編譯器的編譯過程是不一樣的。

Client Compiler
Client Compiler是一個簡單快速的三段式編譯器，主要的關注點在於區域性性的優化，而放棄了許多耗時較長的全域性優化手段。

• 第一個階段，一個平臺獨立的前端將位元組碼構造成一種高階中間程式碼表示（High Level Intermediate Representaion,HIR）。 HIR使用靜態單分配（Static Single Assignment,SSA）的形式來代表程式碼值，這可以使得一些在HIR的構造過程之中和之後進行的優化動作更容易實現。 在此之前編譯器會在位元組碼上完成一部分基礎優化，如方法內聯、常量傳播等優化將會在位元組碼被構造成HIR之前完成。
• 第二個階段，一個平臺相關的後端從HIR中產生低階中間程式碼表示（Low-Level Intermediate Representation,LIR），而在此之前會在HIR上完成另外一些優化，如空值檢查消除、範圍檢查消除等，以便讓HIR達到更高效的程式碼表示形式。
• 最後階段是在平臺相關的後端使用線性掃描演算法（Linear Scan Register Allocation）在LIR 上分配暫存器，並在LIR上做窺孔（Peephole）優化，然後產生機器程式碼。

Server Compiler
Server Compiler則是專門面向服務端的典型應用併為服務端的效能配置特別調整過的編譯器，也是一個充分優化過的高階編譯器，幾乎能達到GNU C++編譯器使用-O2引數時的優化強度，它會執行所有經典的優化動作，

• 無用程式碼消除（Dead Code Elimination）、
• 迴圈展開（Loop Unrolling）、
• 迴圈表示式外提（Loop Expression Hoisting）、
• 消除公共子表示式（Common Subexpression Elimination）、
• 常量傳播（Constant Propagation）、
• 基本塊重排序（Basic Block Reordering），
• 還會實施與Java語言特性密切相關的優化技術，如範圍檢查消除（Range Check Elimination）、 空值檢查消除（Null Check Elimination，不過並非所有的空值檢查消除都是依賴編譯器優化的，有一些是在程式碼執行過程中自動優化了）等。 另外，還可能根據直譯器或Client Compiler提供的效能監控資訊，進行一些不穩定的激進優化，如守護內聯（Guarded Inlining）、分支頻率預測（Branch Frequency Prediction）等。

Server Compiler編譯速度依然遠遠超過傳統的靜態優化編譯器，而且它相對於Client Compiler 編譯輸出的程式碼質量有所提高，可以減少原生代碼的執行時間，從而抵消了額外的編譯時間開銷。

2.4 檢視及分析即時編譯結果

引數-XX：+PrintCompilation要求虛擬機器在即時編譯時將被編譯成原生代碼的方法名稱打印出來
%的輸出說明是由回邊計數器觸發的OSR編譯；

public class Test {
    public static final int NUM = 15000;

    public static int doubleValue(int i) {
        // 這個空迴圈用於後面演示JIT程式碼優化過程
        for(int j=0; j<100000; j++);
        return i * 2;
    }

    public static long calcSum() {
        long sum = 0;
        for (int i = 1; i <= 100; i++) {
            sum += doubleValue(i);
        }
        return sum;
    }

    public static void main(String[] args) {
        for (int i = 0; i < NUM; i++) {
            calcSum();
        }
    }
}

[email protected]:~/IdeaProjects/jvm_in_action/src$ javac  ch11/Test.java 
[email protected]:~/IdeaProjects/jvm_in_action/src$ java -XX:+PrintCompilation ch11.Test
     77    1       3       java.lang.String::hashCode (55 bytes)
     77    2       3       java.lang.String::equals (81 bytes)
     79    3       3       java.lang.String::charAt (29 bytes)
     79    4       3       java.lang.String::length (6 bytes)
     81    6       3       java.lang.Object::<init> (1 bytes)
     81    5       1       java.lang.ref.Reference::get (5 bytes)
     83    8     n 0       java.lang.System::arraycopy (native)   (static)
     83    7       3       java.lang.String::indexOf (70 bytes)
     83   11       3       java.lang.Math::min (11 bytes)
     83    9       3       java.lang.AbstractStringBuilder::ensureCapacityInternal (27 bytes)
     84   10       3       java.util.Arrays::copyOfRange (63 bytes)
     85   12       1       java.lang.ThreadLocal::access$400 (5 bytes)
     85   13       3       java.lang.AbstractStringBuilder::append (50 bytes)
    118   14 %     3       ch11.Test::doubleValue @ 2 (18 bytes)
    119   15       3       ch11.Test::doubleValue (18 bytes)
    119   16 %     4       ch11.Test::doubleValue @ 2 (18 bytes)
    120   14 %     3       ch11.Test::doubleValue @ -2 (18 bytes)   made not entrant
    120   17       4       ch11.Test::doubleValue (18 bytes)
    121   15       3       ch11.Test::doubleValue (18 bytes)   made not entrant
    121   18       3       ch11.Test::calcSum (26 bytes)
    122   19 %     4       ch11.Test::calcSum @ 4 (26 bytes)
    124   20       4       ch11.Test::calcSum (26 bytes)
    126   18       3       ch11.Test::calcSum (26 bytes)   made not entrant
[email protected]:~/IdeaProjects/jvm_in_action/src$ 

這裡不做詳細解釋

3 編譯優化技術
優化技術一覽

針對某個例子的程式碼優化

• 方法內聯的重要性要高於其他優化措施，它的主要目的有兩個，一是去除方法呼叫的成本（如建立棧幀等），二是為其他優化建立良好的基礎，方法內聯膨脹之後可以便於在更大範圍上採取後續的優化手段，從而獲取更好的優化效果。 因此，各種編譯器一般都會把內聯優化放在優化序列的最靠前位置。
• 冗餘訪問消除（Redundant Loads Elimination），假設程式碼中間註釋掉的“dostuff……”所代表的操作不會改變b.value的值，那就可以把“z=b.value”替換為“z=y”，因為上一句“y=b.value”已經保證了變數y與b.value是一致的，這樣就可以不再去訪問物件b的區域性變量了。 如果把b.value看做是一個表示式，那也可以把這項優化看成是公共子表示式消除（Common Subexpression Elimination）
• 複寫傳播（Copy Propagation），因為在這段程式的邏輯中並沒有必要使用一個額外的變數“z”，它與變數“y”是完全相等的，因此可以使用“y”來代替“z”
• 無用程式碼消除（Dead Code Elimination）。無用程式碼可能是永遠不會被執行的程式碼，也可能是完全沒有意義的程式碼

經典優化技術

• 語言無關的經典優化技術之一：公共子表示式消除。
• 語言相關的經典優化技術之一：陣列範圍檢查消除。
• 最重要的優化技術之一：方法內聯。
• 最前沿的優化技術之一：逃逸分析。

公共子表示式消除

• 如果一個表示式E已經計算過了，並且從先前的計算到現在E中所有變數的值都沒有發生變化，那麼E的這次出現就成為了公共子表示式。
• 優化僅限於程式的基本塊內 – 區域性公共子表示式消除（Local Common Subexpression Elimination）; 優化的範圍涵蓋了多個基本塊 – 全域性公共子表示式消除（Global CommonSubexpression Elimination）

int d= (c * b)*12+a+ (a + b * c)

# 編譯器檢測到“c * b”與“b* c”是一樣的表示式，而且在計算期間b與c的值是不變的。
int d=E*12+a+(a+E)；

陣列邊界檢查消除

• 在Java語言中訪問陣列元素foo[i]的時候系統將會自動進行上下界的範圍檢查，即檢查i必須滿足i＞=0＆＆i＜foo.length這個條件，否則將丟擲一個執行時異常：java.lang.ArrayIndexOutOfBoundsException。 但是對於虛擬機器的執行子系統來說，每次陣列元素的讀寫都帶有一次隱含的條件判定操作，對於擁有大量陣列訪問的程式程式碼　– 效能負擔。
• 如果編譯器只要通過資料流分析就可以判定迴圈變數的取值範圍永遠在區間[0，foo.length）之內，那在整個迴圈中就可以把陣列的上下界檢查消除，這可以節省很多次的條件判斷操作。

if (foo != null) {
     return foo.value;
    } else {
     throw new NullPointerException();
}

# 虛擬機器隱式優化;
try {
    return foo.value;
} catch (Segment_Fault e) {
    uncommon_trap(e);
}

• 虛擬機器會註冊一個Segment Fault訊號的異常處理器（虛擬碼中的uncommon_trap（）），這樣當foo不為空的時候，對value的訪問是不會額外消耗一次對foo判空的開銷的。代價就是當foo真的為空時，必須轉入到異常處理器中恢復並丟擲NullPointException異常，這個過程必須從使用者態轉到核心態中處理，結束後再回到使用者態，速度遠比一次判空檢查慢。 當foo極少為空的時候，隱式異常優化是值得的，但假如foo經常為空的話，這樣的優化反而會讓程式更慢，HotSpot虛擬機器會根據執行期收集到的Profile資訊自動選擇最優方案。

方法內聯

• 方法內聯的優化行為只是把目標方法的程式碼“複製”到發起呼叫的方法之中，避免發生真實的方法呼叫而已。 但是即時編譯器其實還是做了很多工作的，否則無法進行內聯 – 因為Java中只有使用invokespecial指令呼叫的私有方法、例項構造器、父類方法以及使用invokestatic指令進行呼叫的靜態方法才是在編譯期進行解析的，除了上述4種方法之外，其他的Java方法呼叫都需要在執行時進行方法接收者的多型選擇，並且都有可能存在多於一個版本的方法接收者（final方法使用invokevirtual指令呼叫，但也是非虛方法），簡而言之，Java語言中預設的例項方法是虛方法。對於一個虛方法，編譯期做內聯的時候根本無法確定應該使用哪個方法版本。
• 為了解決虛方法的內聯問題，Java虛擬機器引入了”型別繼承關係分析”（Class Hierarchy Analysis,CHA）技術，其基於整個應用程式的型別進行分析，用於確定在目前已載入的類中，某個介面是否有多於一種的實現，某個類是否存在子類、子類是否為抽象類等資訊。編譯器在進行內聯時，如果是非虛方法，那麼直接進行內聯就可以了，這時候的內聯是有穩定前提保障的。如果遇到虛方法，則會向CHA查詢此方法在當前程式下是否有多個目標版本可供選擇，如果查詢結果只有一個版本，那也可以進行內聯，不過這種內聯就屬於激進優化，需要預留一個“逃生門”（Guard條件不成立時的Slow Path），稱為守護內聯（Guarded Inlining）。如果程式的後續執行過程中，虛擬機器一直沒有載入到會令這個方法的接收者的繼承關係發生變化的類，那這個內聯優化的程式碼就可以一直使用下去。但如果載入了導致繼承關係發生變化的新類，那就需要拋棄已經編譯的程式碼，退回到解釋狀態執行，或者重新進行編譯。
• 如果向CHA查詢出來的結果是有多個版本的目標方法可供選擇，則編譯器會使用內聯快取（Inline Cache）來完成方法內聯，這是建立在目標方法正常入口之前的快取，它的工作原理大致是：在未發生方法呼叫之前，內聯快取狀態為空，當第一次呼叫發生後，快取記錄下方法接收者的版本資訊，並且每次進行方法呼叫時都比較接收者版本，如果以後進來的每次呼叫的方法接收者版本都是一樣的，那這個內聯還可以一直用下去。如果方法接收者不一致 – 說明程式真正使用了虛方法的多型特性，這時才會取消內聯，查詢虛方法表進行方法分派。

public static void foo(Object object) {
    if (object != null) {
        System.out.println("ok.");
    }
}

public static void testInline(String[] args) {
    Object object = null;
    foo(object);
}

逃逸分析
逃逸分析與型別繼承關係分析一樣，並不是直接優化程式碼的手段，而是為其他優化手段提供依據的分析技術.
逃逸分析的基本行為就是分析物件動態作用域：當一個物件在方法中被定義後，它可能被外部方法所引用，例如作為呼叫引數傳遞到其他方法中，稱為方法逃逸。甚至還有可能被外部執行緒訪問到，譬如賦值給類變數或可以在其他執行緒中訪問的例項變數，稱為執行緒逃逸。如果能證明一個物件不會逃逸到方法或執行緒之外，也就是別的方法或執行緒無法通過任何途徑訪問到這個物件，則可能為這個變數進行一些高效的優化。

• 棧上分配（Stack Allocation）：Java虛擬機器中，Java堆中的物件對於各個執行緒都是共享和可見的，只要持有這個物件的引用，就可以訪問堆中儲存的物件資料。虛擬機器的GC可以回收堆中不再使用的物件，但回收動作包括篩選可回收物件，回收和整理記憶體都需要耗費時間。如果確定一個物件不會逃逸出方法之外，那讓這個物件在棧上分配記憶體將會非常好 – 物件所佔用的記憶體空間就可以隨棧幀出棧而銷燬。在一般應用中，不會逃逸的區域性物件所佔的比例很大，如果能使用棧上分配，那大量的物件就會隨著方法的結束而自動銷燬了，GC的壓力將會小很多。
• 同步消除（Synchronization Elimination）：執行緒同步本身是一個相對耗時的過程，如果逃逸分析能夠確定一個變數不會逃逸出執行緒，無法被其他執行緒訪問，那這個變數的讀寫肯定就不會有競爭，對這個變數實施的同步措施也就可以消除掉。
• 標量替換（Scalar Replacement）：標量（Scalar）是指一個數據已經無法再分解成更小的資料來表示了，Java虛擬機器中的原始資料型別（int、long等數值型別以及reference型別等）都不能再進一步分解，它們就可以稱為標量。相對的，如果一個數據可以繼續分解，那它就稱作聚合量（Aggregate），Java中的物件就是最典型的聚合量。如果把一個Java物件拆散，根據程式訪問的情況，將其使用到的成員變數恢復原始型別來訪問就叫做標量替換。如果逃逸分析證明一個物件不會被外部訪問，並且這個物件可以被拆散的話，那程式真正執行的時候將可能不建立這個物件，而改為直接建立它的若干個被這個方法使用到的成員變數來代替。將物件拆分後，除了可以讓物件的成員變數在棧上（棧上儲存的資料，有很大的概率會被虛擬機器分配至物理機器的高速暫存器中儲存）分配和讀寫之外，還可以為後續進一步的優化手段建立條件。

逃逸分析在JDK1.6中不太成熟 – 主要是不能保證逃逸分析的效能收益必定高於它的消耗。如果要完全準確地判斷一個物件是否會逃逸，需要進行資料流敏感的一系列複雜分析，從而確定程式各個分支執行時對此物件的影響。這是一個相對高耗時的過程，如果分析完後發現沒有幾個不逃逸的物件，那這些執行期耗用的時間就白白浪費了，所以目前虛擬機器只能採用不那麼準確，但時間壓力相對較小的演算法來完成逃逸分析。棧上分配實現起來比較複雜。
如果有需要，並且確認對程式執行有益，使用者可以使用引數-XX：+DoEscapeAnalysis來手動開啟逃逸分析，開啟之後可以通過引數-XX：+PrintEscapeAnalysis來檢視分析結果。有了逃逸分析支援之後，使用者可以使用引數-XX：+EliminateAllocations來開啟標量替換，使用+XX：+EliminateLocks來開啟同步消除，使用引數-XX：+PrintEliminateAllocations檢視標量的替換情況。
Java中非逃逸物件的標量替換優化可以看做是一種高度優化後的棧上分配，但它相當於把物件拆散成區域性變數再進行的棧上分配，而不是C/C++那種程式程式碼可控的棧上分配方式。
4 Java與C/C++的編譯器對比

• 主要靠直譯器執行的Java語言效能確實比較低下，但是Java的即時編譯器能做得非常好。
• Java虛擬機器的即時編譯器與C/C++的靜態優化編譯器相比，可能會由於下列這些原因而導致輸出的原生代碼有一些劣勢（下面列舉的也包括一些虛擬機器執行子系統的效能劣勢）
• 第一，因為即時編譯器執行佔用的是使用者程式的執行時間，具有很大的時間壓力，它能提供的優化手段也嚴重受制於編譯成本。如果編譯速度不能達到要求，那使用者將在啟動程式或程式的某部分察覺到重大延遲，這點使得即時編譯器不敢隨便引入大規模的優化技術，而編譯的時間成本在靜態優化編譯器中並不是主要的關注點。
• 第二，Java語言是動態的型別安全語言，這就意味著需要由虛擬機器來確保程式不會違反語言語義或訪問非結構化記憶體。 從實現層面上看，這就意味著虛擬機器必須頻繁地進行動態檢查，如例項方法訪問時檢查空指標、 陣列元素訪問時檢查上下界範圍、型別轉換時檢查繼承關係等。對於這類程式程式碼沒有明確寫出的檢查行為，儘管編譯器會努力進行優化，但是總體上仍然要消耗不少的執行時間。
• 第三，Java語言中雖然沒有virtual關鍵字，但是使用虛方法的頻率卻遠遠大於C/C++語言，這意味著執行時對方法接收者進行多型選擇的頻率要遠遠大於C/C++語言，也意味著即時編譯器在進行一些優化（如前面提到的方法內聯）時的難度要遠大於C/C++的靜態優化編譯器。
• 第四，Java語言是可以動態擴充套件的語言，執行時載入新的類可能改變程式型別的繼承關係，這使得很多全域性的優化都難以進行，因為編譯器無法看見程式的全貌，許多全域性的優化措施都只能以激進優化的方式來完成，編譯器不得不時刻注意並隨著型別的變化而在執行時撤銷或重新進行一些優化。
• 第五，Java語言中物件的記憶體分配都是堆上進行的，只有方法中的區域性變數才能在棧上分配。而C/C++的物件則有多種記憶體分配方式，既可能在堆上分配，又可能在棧上分配，如果可以在棧上分配執行緒私有的物件，將減輕記憶體回收的壓力。另外，C/C++中主要由使用者程式程式碼來回收分配的記憶體，這就不存在無用物件篩選的過程，因此效率上（僅指執行效率，排除了開發效率）也比垃圾收集機制要高。
• Java語言的這些效能上的劣勢都是為了換取開發效率上的優勢而付出的代價，動態安全、 動態擴充套件、 垃圾回收這些“拖後腿”的特性都為Java語言的開發效率做出了很大貢獻。
• 在C/C++中，別名分析（Alias Analysis）的難度就要遠高於Java。Java的型別安全保證了在類似如下程式碼中，只要ClassA和ClassB沒有繼承關係，那物件objA和objB就絕不可能是同一個物件，即不會是同一塊記憶體兩個不同別名 – 與資料依賴相關的優化才可以進行（重排序、 變數代換）。
• 由於C/C++編譯器所有優化都在編譯期完成，以執行期效能監控為基礎的優化措施它都無法進行，如呼叫頻率預測（Call Frequency Prediction）、分支頻率預測（Branch Frequency Prediction）、裁剪未被選擇的分支（Untaken Branch Pruning）等