編譯過程效能優化的命令列引數

AdoptOpenJDK wiki的一個連結，提供了幾個怎麼提高編譯過程效能的例子。

編譯 jcov

專案首頁(專案資訊, 編譯指南, 其他…)

原始碼:

快速編譯指南

$ hg clone http://hg.openjdk.java.net/code-tools/jcov
$ cd jcov/build
$ ant clean
$ ant -v -f build.xml -Dasmjar5=/path/to/asm-all-5.0.1.jar -Djavatestjar=/path/to/javatest.jar

當專案主頁有編譯指南時，請參考專案主頁，同時上面的編譯編譯指導會被刪掉，避免重複。

編譯 sigtest

專案主頁(專案資訊, 編譯指南, 其他…)

原始碼:

快速編譯指南

$ svn checkout https://svn.java.net/svn/sigtest~svn/trunk
$ cd code/build
$ ant build -Djdk5.home=/path/to/jdk1.5.latest \
-Djdk8.home=/path/to/jdk8.latest \
-Dmvn2.exe=/path/to/latest/bin/mvn

當專案主頁有編譯指南時，請參考專案主頁，同時上面的編譯編譯指導會被刪掉，避免重複。

OpenJDK程式碼覆蓋率

Adopt OpenJDK的程式碼覆蓋率指南

code-coverage.

現存程式碼測試覆蓋率報告 (OpenJDK8 和 OpenJDK9)

我們最近為執行在Adopt OpenJDK 編譯叢集上的 OpenJDK8和 OpenJDK9持續整合增加了程式碼測試覆蓋率報告。自動為OpenJDK8 和OpenJDK9釋出[jcov 報告].

執行OpenJDK9的程式碼測試覆蓋率測試

提示:

• 同樣的步驟也適用於’OpenJDK8′
• 這些步驟僅用於生成’jdk’的測試覆蓋率報告
• 我們沒有能夠成功的生成’langtools’的測試覆蓋率報告
• 保證最新的jdk映像在OpenJDK9編譯生成目錄 (參見 編譯你自己的OpenJDK).
• 安裝 jtreg with the jcov
  , 參見JTReg的使用.
• 把這些exports新增到你的.bash_xxx配置檔案中:

export SOURCE_CODE=/home/<username>/workspace/jdk9/
export JTREG_INSTALL=/home/<username>/workspace/jtreg
export JT_HOME=$JTREG_INSTALL
export JTREG_HOME=$JTREG_INSTALL
export PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk
export JPRT_JTREG_HOME=${JT_HOME}
export JPRT_JAVA_HOME=${PRODUCT_HOME}
export JTREG_TIMEOUT_FACTOR=5
export CONCURRENCY=8

$ cd $SOURCES/jdk9/jdk/test

• 編輯 Makefile 檔案，在 # Make sure jtreg exists行之前增加如下行:

jdkroot=<你的jdk9程式碼路徑, 參見上面>

JTREG_TEST_OPTIONS += -jcov/classes:$(jdkroot)/build/linux-x86_64-normal-server-release/jdk/modules/java.base
JTREG_TEST_OPTIONS += -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes
JTREG_TEST_OPTIONS += -jcov/include:*

debug 模式執行測試

$ cd ..
$ make test LOG=debug

開啟生成的測試覆蓋率報告

一旦結束了, 進入如下路徑檢視報告:

$ cd $SOURCES/jdk9/build/linux-x86_64-normal-server-release/testoutput/jdk_core/JTreport/jcov/
$ open index.html

這會花費幾個小時，具體時間取決於你的系統性能和可用資源。

請參考jcov的編譯。

深入 hotspot 的東西

hotspot 原始碼目錄中的GC選項

../hotspot/src/share/vm/gcimplementation/g1/g1globals.hpp

../hotspot/src/share/vm/runtime/globals.hpp

HotSpot 命令列選項 – PrintAssembly

HotSpot 程式碼片段 – 由於不同GC選項引起的各種分支選擇

參考

Universe::initialize_heap()
if (UseParallelGC) {
    #ifndef SERIALGC
    Universe::_collectedHeap = new ParallelScavengeHeap();
    #else // SERIALGC
        fatal("UseParallelGC not supported in this VM.");
    #endif // SERIALGC
} else if (UseG1GC) {
    #ifndef SERIALGC
    G1CollectorPolicy* g1p = new G1CollectorPolicy();
    G1CollectedHeap* g1h = new G1CollectedHeap(g1p);
    Universe::_collectedHeap = g1h;
    #else // SERIALGC
        fatal("UseG1GC not supported in java kernel vm.");
    #endif // SERIALGC
} else {
    GenCollectorPolicy* gc_policy;
    if (UseSerialGC) {
        gc_policy = new MarkSweepPolicy();
    } else if (UseConcMarkSweepGC) {
        #ifndef SERIALGC
        if (UseAdaptiveSizePolicy) {
            gc_policy = new ASConcurrentMarkSweepPolicy();
        } else {
            gc_policy = new ConcurrentMarkSweepPolicy();
        }
        #else // SERIALGC
            fatal("UseConcMarkSweepGC not supported in this VM.");
        #endif // SERIALGC
    } else { // default old generation
        gc_policy = new MarkSweepPolicy();
    }
    Universe::_collectedHeap = new GenCollectedHeap(gc_policy);
}

開啟序列GC – 只支援序列GC的平臺?

.
.
.
Universe::initialize_heap()
if (UseParallelGC) {
        fatal("UseParallelGC not supported in this VM.");
} else if (UseG1GC) {
        fatal("UseG1GC not supported in java kernel vm.");
} else {
    GenCollectorPolicy* gc_policy;
    if (UseSerialGC) {
        gc_policy = new MarkSweepPolicy();
    } else if (UseConcMarkSweepGC) {
            fatal("UseConcMarkSweepGC not supported in this VM.");
    } else { // default old generation
        gc_policy = new MarkSweepPolicy();
    }
    Universe::_collectedHeap = new GenCollectedHeap(gc_policy);
}
.
.
.

關閉序列GC – 支援並行和序列兩種GC方式的平臺?

.
.
.
Universe::initialize_heap()

if (UseParallelGC) {
    Universe::_collectedHeap = new ParallelScavengeHeap();
} else if (UseG1GC) {
    G1CollectorPolicy* g1p = new G1CollectorPolicy();
    G1CollectedHeap* g1h = new G1CollectedHeap(g1p);
    Universe::_collectedHeap = g1h;
} else {
    GenCollectorPolicy* gc_policy;

    if (UseSerialGC) {
        gc_policy = new MarkSweepPolicy();
    } else if (UseConcMarkSweepGC) {
        if (UseAdaptiveSizePolicy) {
            gc_policy = new ASConcurrentMarkSweepPolicy();
        } else {
            gc_policy = new ConcurrentMarkSweepPolicy();
        }
    } else { // default old generation
        gc_policy = new MarkSweepPolicy();
    }

    Universe::_collectedHeap = new GenCollectedHeap(gc_policy);
}
.

編譯器相關

OptViewer工具，參考這個郵件。

修改 java.c，使用 Eclipse執行 hotspot

[可選，但很有意思的一個挑戰] 請參考這些指南。

修改 java.c，使用命令列執行 hotspot

[可選，但很有意思的一個挑戰]

和修改java.c並在 Eclipse執行的挑戰類似，但是使用需要使用命令列和一個簡單的編輯器來完成這一挑戰。

敬請期待

• Nashorn的一些好東西
• Lambda進階
• OpenJDK(JDK)程式碼測試覆蓋率工具（兩個）
• OpenJDK build warnings tool (which are currently suppressed in the build process)…
• OpenJDK 編譯警告工具（當前在編譯過程中被禁用）
• 使用 jitWatch觀察 HotSpot JVM JIT編譯過程
• 執行在 JVM 上的Smalltalk
• 執行在 JVM 上的Lisp

Hotspot JVM 任務: 附加任務 (中級和高階)

• 向 java.c 中增加 debug 級別的 log資訊，重新編譯 gamma，執行示例程式或者任何其他基於 java 的程式。
• 重構 java.c，插入 debug 級別的 Log細膩，重新編譯 gamma，執行示例程式或者任何其他基於 java 的程式。
• 完成以上兩步後，載入一個低延遲，GC 調優過的 java 程式，開啟 gc log，檢查 gc log，看效能是否有變化（效能調優相關的東西）。
• 在 javac 中實現 ?:運算子(學習怎麼修改 javac 的好方法)，編譯一個java 程式。
• 體味GC 的樂趣：使用自定義的垃圾收集器替換已有的。重新啟用程式碼庫中的 PermGen 或者 iCMS 。在現在 HotSpot 版本中增加任意你想做的修改。
• 修改 javac 使他能夠解析和編譯新的語言特性，或者讓它能夠相容其他基於 JVM 的方言、甚至於更老的程式語言，例如 C、彙編、Scheme 或Smalltalk
• 使用自定義類載入器替換內建內載入器。