TornadoVM

"Write Java. Run on GPUs. Fast." — a compiler and runtime that takes ordinary Java methods and executes them on GPUs, multi-core CPUs and FPGAs. The 6.0.0 install table names three backends — OpenCL (the default: NVIDIA/AMD/Intel GPUs, multi-core CPUs, FPGAs), CUDA (NVIDIA, with tensor cores and cuBLAS/cuFFT/cuDNN library tasks) and a new Metal one (Apple Silicon M1–M4, natively via MSL). Apache-2.0, Java, from the University of Manchester's Beehive Lab. Repository created 2018-09-07; 1,496★ / 141 forks on 2026-09-07. 6.0.0 went GA on 2026-09-02, reported the same week by InfoQ's Java roundup.

Why it sits in a languages wiki

It is a page about the host, not about Java the language. hosted-language argues that a language defines what programs mean while a runtime decides what they can do; TornadoVM is the case where somebody enlarges what the runtime can do without touching the language at all. The same Java source runs somewhere the JVM was never able to put it. clojure, kotlin and jank are the inverse move — new languages on an existing host.

6.0.0, and the two changes that are really about the JDK

• JNI is gone from the backends and library tasks, replaced by the Foreign Function & Memory API (release entry #1058). The FFM API is the JDK's replacement for the Java Native Interface, so this is a downstream project moving onto the platform's new native-interop story.
• The JVMCI dependency was removed (#894) — and the release notes give the reason the InfoQ column omits: "for JDK27+ backwards compatibility for JDKs 21-26." Compiler metadata now comes through a reflection + ASM + Unsafe layer, described as the single uniform path across JDK 21, 25, 26 and 27.

Both are worth holding for java's sake. The spoke has no source describing the JVM's evolution, and here is a project rewriting two of its interfaces to the runtime in one release because the runtime moved underneath it. JVMCI is an experimental interface, and this is what depending on one costs.

The rest of 6.0.0

CUDA gained native FP8 (E4M3/E5M2) conversion, FP8/BF16 tensor-core MMA and cp.async copies, plus hybrid library-task providers over cuDNN, cuFFT, cuSPARSE and CUTLASS; Apple M-silicon Metal gained hardware matrix units (simdgroup_float8x8) for fast GEMMs. The direction is unmistakable — this release is largely about making Java a plausible place to run the same kernels an ML stack would.

Noted for ../agentic-tooling-wiki, not paged here: the release also ships two agent skills for its own contributors (#980, a contributor Claude skill for OpenCL/CUDA/Metal; #1038, a tornadovm-perf-campaign skill with profiling recipes and a probe harness).

Not yet examined

Everything above is the repository's own record. Nothing here measures TornadoVM against hand-written CUDA, or against Java on a CPU, and the project's own benchmarks were not read for this page. The tornadovm.org site is unread.

Related

java · hosted-language · java-news-roundup-aug31-2026 · kotlin · programming-language · synthesis