TornadoVM

Write Java. Run on GPUs. Fast.

TornadoVM is a GPU programming framework for Java that works with JDK 21+ (currently JDK 21, JDK 25, JDK 26, and JDK 27). It JIT-compiles Java bytecode into NVIDIA CUDA, OpenCL C, and Apple Metal (MSL) at runtime, so your existing Java code runs on NVIDIA GPUs (via CUDA), AMD, Intel, and Apple Silicon GPUs, integrated GPUs, and multi-core CPUs. On NVIDIA hardware it goes further: beyond generating CUDA, TornadoVM now calls straight into the NVIDIA library ecosystem — cuBLAS, cuFFT, cuDNN — and exposes Tensor Core mma.sync instructions from pure Java. No CUDA C. No JNI bindings to maintain. No native toolchain in your application. Latest release: TornadoVM 6.1.0 (JDK 21 - JDK 27) — native NVIDIA library integration (cuBLAS / cuFFT / cuDNN) and Tensor Core intrinsics, plus a native Apple Metal backend for Apple Silicon. Changelog · Website · Documentation

This is the whole programming model

Write the kernel in Java with the same thread-indexing model you'd use in CUDA — then build a task graph and execute. TornadoVM JIT-compiles the bytecode to a GPU kernel at runtime and manages all host↔device data transfers for you. On NVIDIA GPUs that kernel is emitted as CUDA PTX and compiled through NVRTC to a native cubin.

void mxv(KernelContext ctx,
         FloatArray m,
         FloatArray v,
         FloatArray out,
         int rows, int cols) {
  int i = ctx.globalIdx;
  if (i < rows) {
    float sum = 0f;
    for (int j=0; j<cols; j++)
      sum += m.get(i*cols+j)*v.get(j);
    out.set(i, sum);
  }
}

// TornadoVM auto-manages device
// memory + kernel dispatch via a
// TaskGraph — no host plumbing,
// runs unchanged on all 4 backends.

__global__ void mxv(
    const float *m,
    const float *v,
    float *out,
    int rows, int cols) {
  int i = blockIdx.x*blockDim.x
        + threadIdx.x;
  if (i < rows) {
    float sum = 0.f;
    for (int j=0; j<cols; j++)
      sum += m[i*cols+j]*v[j];
    out[i] = sum;
  }
}

// ...and on the host you STILL write:
//   cudaMalloc/cudaMemcpy per buffer
//   grid/block dims, launch, sync
//   cudaMemcpy back, then cudaFree
//   nvcc build + per-GPU binaries
//   + a rewrite for non-NVIDIA GPUs

…and the host side — wrap data, map a thread grid, execute (click to expand)

…

KernelContext gives you the full GPU programming model — global/local thread IDs, local memory, and barriers, the same semantics as CUDA/OpenCL/SYCL — while TornadoVM handles memory management and runs the identical code across all four backends. Don't need that control? Drop KernelContext and just annotate the loop with @Parallel — TornadoVM infers the thread mapping for you. Both styles combine in the same TaskGraph. Programming guide →

The NVIDIA ecosystem, native to Java

On NVIDIA hardware, TornadoVM is more than a PTX code generator — it's an open-source on-ramp to the whole CUDA software stack, callable from the same TaskGraph you already use. Generated kernels and native library calls share TornadoVM-managed device buffers on one CUDA stream, so a JIT-compiled kernel can feed a cuBLAS call and consume its output with no extra copies and no host synchronization.

Mixing your own kernels with NVIDIA's tuned libraries looks like this:

…

Library bindings are discovered via Java ServiceLoader — implement TornadoLibraryProvider, bind the calls through java.lang.foreign (a JNI module only if the library genuinely needs compiled C/C++), and any native library joins the graph with no core runtime changes. TornadoVM is a member of the NVIDIA Inception Program and has presented this work at NVIDIA GTC. Hybrid API guide →

What people build with it

TornadoVM is used to accelerate machine learning and deep learning, computer vision, physics simulations, financial applications, computational photography, and signal processing. Building something with TornadoVM? Tell us — we feature community projects.

⚡ Quick start

Prerequisites

• JDK 21 (or GraalVM based on JDK 21) — JAVA_HOME must point to it
• GCC/G++ ≥ 13, plus the driver for your target (OpenCL runtime, CUDA Toolkit, or macOS for Metal)
• For the NVIDIA library tasks (cuBLAS / cuFFT / cuDNN): the CUDA Toolkit with the corresponding libraries; on systems with multiple toolkits, /usr/local/cuda (or $CUDA_PATH) is preferred

Install via SDKMAN!

sdk install tornadovm

Pick a backend-specific build if you prefer a smaller install. Candidate versions are per-JDK (swap jdk21 below for jdk22plus to install a build for that JDK line):

Binaries are also on the official website. For Docker and AWS (CPUs/GPUs) see the linked guides.

Verify your devices

tornado --devices

Run your first program

# Unix (Linux/macOS)
java @$TORNADOVM_HOME/tornado-argfile \
  -cp $TORNADOVM_HOME/share/java/tornado/tornado-examples-6.1.0.jar \
  uk.ac.manchester.tornado.examples.compute.MatrixVectorRowMajor

# Windows 10+
java @%TORNADOVM_HOME%\tornado-argfile ^
  -cp %TORNADOVM_HOME%\share\java\tornado\tornado-examples-6.1.0.jar ^
  uk.ac.manchester.tornado.examples.compute.MatrixVectorRowMajor

More examples — NBody, DFT, KMeans, matrix kernels, reductions: tornado-examples

Use TornadoVM in your project

Maven Central coordinates are per-JDK — pin the -jdk21 / -jdk22plus version matching the JDK you build with:

<dependencies>
  <dependency>
    <groupId>io.github.beehive-lab</groupId>
    <artifactId>tornado-api</artifactId>
    <version>6.1.0-jdk21</version>
  </dependency>
  <dependency>
    <groupId>io.github.beehive-lab</groupId>
    <artifactId>tornado-runtime</artifactId>
    <version>6.1.0-jdk21</version>
  </dependency>
</dependencies>

❓ FAQ

Project Babylon is OpenJDK's exploratory work on code reflection, with HAT (Heterogeneous Accelerator Toolkit) as a research vehicle for GPU programming. We think it validates the direction TornadoVM has pursued since 2018 — and the projects are complementary rather than competing. The practical difference today: TornadoVM is usable now, with three production backends (OpenCL, CUDA, Metal), a profiler, dynamic reconfiguration, Maven Central artifacts, and years of hardening across vendor hardware — and it runs on standard JDK 21/25 releases. We follow Babylon closely and expect the ecosystems to converge over time.

On NVIDIA hardware TornadoVM JIT-compiles your Java kernels to CUDA PTX and compiles them through NVRTC to native cubins. On top of that, it integrates the NVIDIA software ecosystem directly into the TaskGraph: cuBLAS / cuBLASLt (including TF32 and FP16 GemmEx on Tensor Cores and fused epilogues), cuFFT, and cuDNN (including fused flash attention) are available as library tasks that share device buffers and a CUDA stream with your generated kernels. You can also target Tensor Cores directly from Java via mma.sync intrinsics (FP16 and INT8), and capture the whole pipeline into a CUDA Graph for single-launch replay. See The NVIDIA ecosystem, native to Java.

The parts your application links against — Tornado-API and all the modules you code with — are Apache 2.0. The runtime and drivers are GPLv2 with Classpath Exception, the same license as OpenJDK itself: it does not impose copyleft obligations on your application, exactly as running on OpenJDK doesn't. Full per-module breakdown below.

No. TornadoVM is a plug-in to your existing OpenJDK or GraalVM installation. It complements the JVM with the ability to offload selected tasks to accelerators, handling device memory management and kernel orchestration. Everything else in your application runs on the JVM as normal.

Multi-core CPUs; dedicated GPUs from NVIDIA, AMD, and Intel; and integrated GPUs (Apple Silicon M1–M4, Intel HD Graphics, ARM Mali). Backends can be installed individually or together, and tasks can migrate between devices at runtime. NVIDIA GPUs can be driven either through the CUDA backend (with the library and Tensor Core features above) or through the OpenCL backend.