01 背景
Alibaba Dragonwell 作爲 OpenJDK 的下游版本，是阿里巴巴針對 10萬+ 服務器上運行的在線電商、金融、物流應用優化的 OpenJDK 實現。 阿里巴巴和 OpenJDK 社區緊密合作，將盡可能多的 Alibaba Dragonwell 定製功能帶到上游。Dragonwell 是 OpenAnolis 的默認 JDK，Alibaba 的衆多 Java 應用，正在逐步遷移到 Dragonwell 上。
Intel Java 團隊長期致力於 OpenJDK 的發展，貢獻了大量優化特性，這些工作使得 OpenJDK 可以更好利用現代 CPU 的強大特性。VectorAPI 是 Java 在特定領域進行高性能計算的利器，廣大 Java 開發者通過 VectorAPI 可以精確地控制和利用現代 CPU 普遍存在的 SIMD (Single Instruction Multiple Data) 硬件單元，特定的應用可以獲得數倍以上的性能提升。
02 Java 高性能計算現狀
SIMD 計算單元在 X86 平臺(非 X86 平臺也普遍存在 SIMD)上從 MMX(Multi Media eXtension)時代，演進到當前的 AVX-512 (Advanced Vector Extensions)/AMX(Advanced Matrix Extensions)時代，SIMD 技術在多媒體處理，遊戲娛樂，大數據處理和最近火熱的 AI 領域都發揮了至關重要的作用。開發者可以利用 C/C++（intrinsic指令），彙編語言等語言工具顯式的編寫 SIMD 相關代碼（稱之爲向量化編碼）來利用 SIMD 單元；也可以利用編譯器/解釋器的自動向量化功能來進行。JVM(Java Virtual Machine)也具有自動向量化的能力。
在利用編譯器/解釋器的自動向量化功能的時候，雖然開發人員的負擔較小，但由於這些工作都依賴於編譯器/解釋器的實現，很多時候無法達到預期的目的。而開發人員能做的卻很有限，SIMD 硬件的性能往往不能充分發揮；而直接針對 SIMD 硬件編程，較老版本的 Java 卻只能通過 JNI(Java Native Interface)，調用使用 C/C++ 或者彙編語言實現的庫來實現。JNI 的引入，將帶來不容忽視的額外性能開銷；同時混合編程模式也會增加系統管理維護的複雜度。Java VectorAPI (向量 API)的出現，給了 Java 開發者直接面向 SIMD 硬件的編程能力。使用 SIMD 硬件的途徑：
| 自動向量化 | 調用本地語言庫 | 直接針對 SIMD 單元編程 | |
| C/C++、彙編等本地語言 | 是 | 是 | 是 (Intrinsic/彙編) |
| Java | 是 | 是(JNI) | 是(VectorAPI) |
03 VectorAPI 介紹
VectorAPI (Incubator, JEP 338, JEP：JDK Enhancement Proposals) 最初於 2018 年 4 月開始創建，在 OpenJDK16 作爲孵化器項目(2020年10月)被引入。隨着後續 OpenJDK 版本的升級，VectorAPI 也得到了同步升級：
- OpenJDK 17 -> JEP 414，Second Incubator
- OpenJDK 18 -> JEP 417，Third Incubator
- OpenJDK 19 -> JEP 426，Fourth Incubator
- OpenJDK 20 -> JEP 438，Fifth Incubator
每次 VectorAPI 的升級都會帶來性能提升，更多功能和 Bugfix。VectorAPI 的編程使用的是純 Java 代碼，下面看一個簡單例子：
// 傳統寫法實現2個數組相加
void add (float[] A, float[] B, float[] C) {
for (int i = 0; i < C.length; i++) {
C[i] = A[i] + B[i];
}
}
// 使用VectorAPI的2個數組相加
public class AddClass<S extends Vector.Shape<Vector<?, ?>>> {
private final FloatVector.FloatSpecies<S> spec;
AddClass (FloatVector.FloatSpecies<S> v) {spec = v; }
// vector routine for add
void add (float[] A, float[] B, float[] C) {
int i=0;
for (; i + spec.length() < C.length; i += spec.length()) {
FloatVector<S> av = spec.fromArray(A, i);
FloatVector<S> bv = spec.fromArray(B, i);
av.add (bv).intoArray(C, i);
}
// clean up loop
for (; i < a.length; i++) C[i] = A[i] + B[i];
}
}
可以看出，在使用 VectorAPI 後，在支持 AVX-512 的硬件平臺上，一次加法可以處理 (512/32=16) 16 個浮點數；而傳統加法一次只能處理一個浮點數。下面是一些 VectorAPI 的實際例子：
- 高性能計算、AI、多媒體領域廣泛使用的 BLAS (Basic Linear Algebra Subprograms，基本線性代數子程序)，可以得到 2.2X~4.5X 的提升。
- 圖像處理 Sepia 過濾 ，最多得到 6 倍提升：
- 數據庫應用 2 倍以上提升：
- Parquet-Decoder 有 4~8 倍提升：https://github.com/apache/parquet-mr/pull/1011
由於 VectorAPI 是一個比較新的模塊，更多利用 VectorAPI 的新項目正在開發中。
04 業界 Java 版本現狀
在 Apache Parquet-mr 項目中，使用 VectorAPI 需要 JDK17 的支持。一方面 JDK17 是 Java 的 LTS (Long-Term Support) 版本，更爲重要的是前一個 Java LTS 版本 JDK11 並不支持 VectorAPI。但是業界 JDK11 的使用比 JDK17 更爲廣泛，而在成熟的生產環境中升級 Java 版本是一件代價高昂的事情，這就造成了 VectorAPI 在業界推廣使用的一個顯而易見的巨大障礙。對此業界也做了不少努力和嘗試，比如阿里巴巴在其內部使用的 AJDK上，已經加入了 VectorAPI 的支持，但是其實現和 OpenJDK 社區還是有差別，後續的升級維護不是一件容易的事情。因此阿里巴巴和英特爾開始了將 VectorAPI (JEP 338)移植到 Dragonwell11 上的項目。這樣既可以利用 VectorAPI 的強大功能，又保護了現在的投資，避免了升級 JDK 的風險。
05 移植難點
- 涉及代碼量巨大
社區 JEP 338 涉及 336 文件修改，涉及代碼行數 29 萬行。而這些都是以 JDK16 爲基準的和基於 JDK11 的 Dragonwell 相比，差異會更大。
- 保持和上游 OpenJDK 的關聯
而且一方面要讓 Dragonwell11 能繼續方便追蹤上游 OpenJDK11 的修正增強，還要讓 VectorAPI 也能較爲方便跟蹤上游 OpenJDK 後續 VectorAPI 的演進，對移植工作帶來了不小挑戰。
- 性能要和上游 OpenJDK 接近
OpenJDK11 以後的版本的一些性能相關改動以及如何引入 Dragonwell11?
- 穩定可靠的強需求
Dragonwell 需要支持現有的大量業務，穩定可靠是第一位的要求。
06 解決方案
針對海量的代碼，阿里巴巴和英特爾都投入了大量資源，其中雙方都包括了上游 OpenJDK 社區 VectorAPI 的關鍵貢獻者，雙方緊密合作，討論方案，檢查代碼。在移植過程中，儘量保持 Dragonwell11 的原有結構，只涉及 VectorAPI 的部分才採用上游的實現。一些上游 JDK11 以後的改動，分析其實現，如果可以使用現有 Dragonwell11 的組件，就不引入額外的改動。這樣把對 Dragonwell11 的影響降到最小。並且利用 OpenJDK 內建的測試集，完整覆蓋移植後的 Dragonwell11，來保證移植的質量。
07 Dragonwell11 + VectorAPI
目前，VectorAPI 已經合併到 Dragonwell11 的主分支(master)，且完全兼容 VectorAPI 1st Incubator (JEP 338)，後續還會把 JEP 414、JEP 417、JEP 426、JEP 438 的功能移植到 Dragonwel11 上。
相關鏈接：
Alibaba Dragonwell：https://github.com/alibaba/dragonwell11
OpenJDK ：https://github.com/openjdk/jdk
文/朱文傑、金鐘暉
本文爲阿里雲原創內容，未經允許不得轉載。