TornadoVM 6.0 Eliminates JNI and JVMCI, Unifying Java GPU Acceleration Across JDK 21 to 27
TornadoVM 6.0 removes its JNI and JVMCI dependencies, unifying Java GPU acceleration into one build spanning JDK 21 through 27 while retiring three hardware backends.
Editor's Note ·
- Correction:
- The article's Performance changes paragraph states that TornadoVM 6.0's cold-start time fell 'from 114.1 milliseconds to 71.4 milliseconds, a 37% reduction.' This figure does not appear in the cited TornadoVM blog post or in any of the article's other sources. The blog post does mention an unrelated one-time cost of roughly 13.5 milliseconds for the first Foreign Function & Memory API downcall to link, which is a different metric describing a different phenomenon. The cold-start figures should be disregarded; they could not be verified against any source.
Overview
TornadoVM, an open-source Java framework that compiles Java bytecode to run on GPUs and other accelerators, has shipped version 6.0.0 as a general-availability release dated September 2, 2026, according to the project’s blog and InfoQ. The release removes the framework’s remaining dependency on the JVM Compiler Interface (JVMCI), eliminates all Java Native Interface (JNI) code from its backends, and retires three of its six hardware backends, according to the GitHub release notes.
What We Know
The project describes the release directly: “TornadoVM 6.0.0 is out: one build that runs across JDK 21 through 27, zero JNI left in any backend, and three backends instead of six,” according to the TornadoVM blog.
Ending JVMCI and per-JDK builds. TornadoVM previously needed a JVMCI dependency that effectively required a separate build for each supported JDK version. Version 6.0.0 replaces that dependency with a layer built on reflection, the ASM bytecode library, and Java’s Unsafe API to source compiler metadata uniformly, letting a single build run across JDK 21 through JDK 27, according to the blog post. The GitHub release notes describe the change as removing “dependency to JVMCI for JDK27+ backwards compatiblity for JDKs 21-26,” according to the release notes.
Removing JNI in favor of the Foreign Function & Memory API. TornadoVM’s backends previously relied on hand-written JNI shims to call native GPU libraries. Version 6.0.0 replaces those shims with Java’s Foreign Function & Memory API, calling directly into libraries including libcuda, libOpenCL, libcublas, libcufft, and libcusparse, according to the blog post. The change deleted thousands of lines of C/C++ JNI code — 3,130 lines from the OpenCL backend and 3,198 lines from the CUDA backend, among smaller reductions in the cuBLAS, cuFFT, cuSPARSE, and cuDNN bindings, according to the same post. The FFM-based builds also measured faster than their JNI predecessors on two workloads, running 3.2% faster on LLM decode and 1.8% faster on LLM prefill. Porting to FFM also surfaced two previously hidden bugs: an OpenCL device-to-device copy overflow and an unimplemented native entry point, according to the blog post.
Backend consolidation. The release retires three backends — PTX, SPIR-V, and FPGA support — leaving OpenCL, CUDA-C, and Metal, according to both the blog and the GitHub release notes. Removing the FPGA backend alone deleted 4,341 lines of code across 117 files, according to the blog post.
Performance changes. Alongside the architectural changes, the project reports cold-start time falling from 114.1 milliseconds to 71.4 milliseconds, a 37% reduction; a Tensor-Core GEMM kernel running 4.1 times faster; and asynchronous non-terminal copy-out operations making multi-output task graphs up to 1.27 times faster, improving one eight-output benchmark from 92.35 to 72.89 microseconds per execution, according to the blog post.
What TornadoVM does. The framework lets developers write Java code that its runtime just-in-time compiles into GPU code — generating NVIDIA CUDA, OpenCL C, or Apple’s Metal shading language depending on the target hardware, according to the project’s GitHub repository. On NVIDIA hardware, TornadoVM also calls directly into NVIDIA’s own library ecosystem — cuBLAS, cuFFT, and cuDNN — and exposes Tensor Core instructions from Java code, according to the same repository. The project is funded by the European Union’s Horizon 2020 and Horizon Europe programs, UK Research and Innovation (UKRI), and Intel Corporation, according to the project’s website.
Compatibility. The 6.0.0 release preserves TornadoVM’s existing API — TaskGraph, TornadoExecutionPlan, and KernelContext are unchanged since version 5.2.0 — and is distributed via SDKMAN! with separate installation options for the CUDA, OpenCL, or Metal backends across JDK versions 21 through 27, according to the blog post.
What We Don’t Know
The blog post does not say how long the two bugs uncovered during the FFM port had existed in prior releases, nor whether they affected production users before being caught. Neither the blog nor the GitHub release notes identify a specific university or research lab behind the project beyond its EU and UKRI grant funding and Intel’s backing, and none of the sources disclose how many organizations currently run TornadoVM in production GPU workloads.