TornadoVM 8 Replaces Graal With a Java GPU Compiler

Concept illustration of a Java development workstation with the TornadoVM TC compiler transforming bytecode into CUDA C++, OpenCL C and Metal shader code

The TornadoVM team released TornadoVM 8.0.0 on October 26, 2026, replacing a decade-old Graal-based compiler with TC, a pure-Java compiler for GPU workloads. The team explained the change in its October 27 technical announcement, describing output targeting NVIDIA CUDA C++, OpenCL C and Apple Metal Shading Language. TornadoVM remains a Java accelerator framework rather than an alternative Java language or standalone GPU driver.

What is TornadoVM? TornadoVM is an open-source Java framework that sends suitable parallel computations to graphics processors and other supported accelerators. Instead of rewriting an entire application in CUDA or OpenCL, developers describe compatible workloads in Java while TornadoVM generates device-specific code and coordinates execution and data movement. The technology targets compute-heavy tasks such as numerical processing, simulations and machine-learning workloads.

Application interfaces such as TaskGraph, TornadoExecutionPlan, KernelContext and the @Parallel and @Reduce annotations remain supported. Developers can keep their existing Java kernels while the runtime builds code for supported GPUs. Readers can revisit the Java source, bytecode and JVM fundamentals to understand where a GPU compiler enters the execution pipeline.

Devoxx hosts Christos Kotselidis and Mary Xekalaki explaining how Java applications use TornadoVM for GPU acceleration. Recorded March 2026, before TC shipped.

The compiler now parses Java class files directly, constructs an intermediate representation using static single assignment, runs optimization passes and emits target-specific source code. Project maintainers say the removal of Graal and JVMCI simplifies JDK support and tooling. The main compiler replacement touched 1,218 files, with 40,166 lines added and 119,699 removed, according to their development record.

Regression tests show measurable but carefully bounded changes. On an NVIDIA RTX 4090, CUDA tests passed rose from 1,516 with Graal to 1,539 with TC, an increase of 23. OpenCL tests on the same GPU increased from 1,027 to 1,057, an increase of 30. Intel UHD 770 OpenCL passes moved from 932 to 934. The authors also disclosed 941 Metal passes against a previous 942, without a new Metal run after Graal was removed. Test counts measure compatibility coverage rather than throughput or energy efficiency.

Chart of Graal and TC compiler regression-test counts on CUDA and OpenCL with zero baseline
TornadoVM 8.0 regression-test counts compare the old Graal compiler and new TC on matching GPU backends. Higher test passes do not establish faster application speed. Data: TornadoVM team, October 27, 2026.

TornadoVM reported selected jitLLM workloads delivering 1.06 to 1.14 times Graal’s throughput on CUDA. Separately, a small CUDA program on an RTX 4090 started and completed in approximately 0.3 seconds using a Project Leyden ahead-of-time cache or GraalVM Native Image, compared with about 0.6 seconds under the conventional JVM. The findings are project-run demonstrations, not independent performance measurements across all Java programs.

Devoxx conference presentation covering Java access to NVIDIA libraries through TornadoVM’s Hybrid API, October 2026. Background context rather than a TornadoVM 8 benchmark.

With the new architecture, TornadoVM supports JDK 21 through 27 and exposes tc emit for inspecting compiled kernels without a GPU attached. Its tornado-selftest utility runs small workloads against available devices and compares results with JVM execution, optionally exporting a JSON report. Developers still need compatible GPU drivers and must test numerical correctness, memory transfers and actual workload performance before deployment. Native Image support does not yet cover certain JNI-based accelerator libraries or Windows.

The underlying challenge is choosing the right processing hardware. BitcoinVersus.Tech’s CPU, GPU, NPU and TPU comparison explains why parallel workloads can behave differently from ordinary sequential programs. Another compiler project, Perry’s native TypeScript compiler, illustrates an independent approach to language-toolchain modernization; its benchmarks cannot be compared directly with GPU kernel tests.

The key developer benefit is continued Java API compatibility with a smaller, more inspectable compiler stack. However, broad adoption will depend on reliable backend support, straightforward diagnostics, and reproducible performance on diverse hardware. The importance of independent code review is also familiar from BitcoinVersus.Tech’s analysis of AI coding-agent review demands. New workloads and third-party tests will reveal how consistently TC delivers its intended improvements.

BitcoinVersus.Tech Editor’s Note: We volunteer daily to ensure the credibility of the information on this platform is Verifiably True. If you would like to support to help further secure the integrity of our research initiatives, please donate using the QR code provided

BitcoinVersus.Tech original 5,000-satoshi donation QR code

For best QR-code scanning results, please scan this donation code from a desktop or larger screen. Mobile screens may prevent camera recognition. Verify the receiving address 3C9o19EH5HSiwEPyCTmEKzxhNCbo2X6TTb before sending.

Disclaimer: BitcoinVersus.Tech is not a financial advisor. This media platform reports on financial subjects purely for informational purposes.

Leave a Reply