WebAssembly

WebAssembly 進駐 JVM:從 Chicory 到 Endive 的效能演進與實務應用

作者

該內容精準地捕捉了 JVM 擺脫 JNI 依賴的技術趨勢,評價為『高實用價值的技術轉型指南』。其核心價值在於將複雜的執行層級(解釋器 vs 編譯器)具象化,邏輯清晰。然而,文中對『併發限制』的討論較為簡略,在面對高併發伺服器場景時,僅靠 Java 層級編排可能不足以完全抵消 Wasm 單執行緒的效能損失。

WebAssembly 進駐 JVM:從 Chicory 到 Endive 的效能演進與實務應用

對於許多 Java 工程師來說,WebAssembly (Wasm) 通常被認為是瀏覽器端用來提升前端效能的技術。但事實上,Wasm 的設計目標是建立一個安全、可移植且高效的二進位指令格式,這使得它在伺服器端,特別是在 JVM (Java Virtual Machine) 上運行,具有巨大的潛力。

本文將探討如何將 Wasm 整合進 JVM,以及其背後的執行策略、實務應用,以及近期從 Chicory 轉型為 Endive 的技術脈絡。

為什麼 JVM 需要 WebAssembly

在 Java 中,若要呼叫非 Java 語言編寫的函式庫,傳統做法是使用 JNI (Java Native Interface)。然而,JNI 存在三個核心痛點:安全性差(原生程式碼錯誤會直接導致 JVM 崩潰)、移植性低(必須針對不同作業系統與 CPU 架構編譯多個版本)、維護成本高。

WebAssembly 提供了一個完美的替代方案。它在 JVM 內建立一個沙箱 (Sandbox) 環境,讓非 Java 程式碼在受控的隔離空間執行。這意味著即使 Wasm 模組內部發生錯誤,也不會導致整個 JVM 崩潰。同時,Wasm 是平台無關的,開發者只需編譯一次 Wasm 檔案,即可在任何安裝了 Wasm 運行時的 JVM 上執行,徹底解決了 JNI 的移植噩夢。

JVM 上的 Wasm 執行策略

要在 JVM 上執行 Wasm,需要一個運行時 (Runtime) 將 Wasm 指令轉換為 JVM 能理解的格式。根據效能需求,通常分為三種執行層級:

純解釋器 (Pure Interpreter) 這是最基礎的實作方式,運行時會逐條讀取 Wasm 指令並直接執行。優點是極高的移植性且無外部依賴,適合對效能要求低但對環境限制極嚴格的場景。缺點是速度最慢,因為它無法觸發 JVM 的 JIT (Just-In-Time) 編譯器優化。

Java 位元碼編譯器 (Java Bytecode Compiler) 這種方式將 Wasm 指令直接翻譯成 Java Bytecode。由於 Wasm 與 Java Bytecode 的結構相似,這種轉換效率很高。一旦轉換完成,生成的 Java 程式碼就能被 JVM 的 C1/C2 編譯器優化,效能可大幅提升 10 倍以上,接近原生效能。

原生組合編譯 (Cranelift-based Assembly) 為了追求極致效能,最新的實驗性方案是引入 Cranelift (一個高效的 Rust 編譯器後端)。透過將 Cranelift 編譯成 Wasm 並在 JVM 中執行,可以將 Wasm 預先編譯為特定 CPU 的機器碼 (Machine Code),使其效能與 Wasmtime 等頂級 Wasm 運行時相當。

實務應用場景

Wasm 在 JVM 上的應用已從實驗階段進入生產環境,常見案例包括:

插件化架構 (Plugin Architecture) 例如 Helm 4 與 Microcks 等工具,允許使用者透過 Wasm 注入自定義插件。開發者可以用 Rust 或 Go 撰寫邏輯,編譯成 Wasm 後交給 Java 主程式執行,既保證了擴展性,又不會因為插件的 Bug 導致主系統當機。

跨語言函式庫複用 許多高效能的解析器 (Parser) 是用 C 撰寫的。例如 Ruby 的官方解析器 Prism,透過 Wasm 可以在 JVM 上直接運行而無需安裝原生庫。同樣地,QuickJS (輕量級 JavaScript 引擎) 也可以透過 Wasm 整合進 Java,讓 Java 應用程式能安全地執行 JavaScript 腳本,而不需要依賴已廢棄的 Nashorn 或重量級的 GraalJS。

邊緣運算 (Edge Computing) Cloudflare 與 Fastly 等 CDN 廠商大量使用 Wasm 執行邊緣邏輯。因為 Wasm 啟動速度極快且記憶體占用低,適合在極高密度的多租戶環境中運行大量小型任務。

限制與挑戰

儘管 Wasm 強大,但目前仍有明顯限制。最主要的是缺乏原生併發 (Concurrency) 與平行處理 (Parallelism) 機制。目前的 Wasm 模組基本上是單執行緒的。如果應用需要多核心平行運算,開發者必須在 Java 層級進行編排 (Orchestration),將任務拆分給多個 Wasm 實例執行。

從 Chicory 到 Endive 的轉型

Chicory 是長期以來在 JVM 上實現 Wasm 的核心專案。為了確保技術的長期穩定性與中立性,該專案決定將其分叉 (Fork) 並移交至 Bytecode Alliance (一個致力於推動 Wasm 標準的工業基金會) 管理,並更名為 Endive。

這次轉型將專案從單一公司維護轉變為社區驅動,旨在讓更多開發者參與貢獻,並確保 Endive 能緊跟 WASI (WebAssembly System Interface) 與 WasmGC (垃圾回收) 等最新標準,成為 JVM 生態系中標準且安全的 Wasm 執行環境。

來源:infoq.com (Podcast: WebAssembly on the JVM: Feature Evolution, Performance, and the Transition to Endive)

本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理,並非原文逐字翻譯。