TornadoVM released version 7.3.0 on October 14, adding Apple MLX library tasks on its Metal backend and Nvidia NCCL communication on GPU buffers. For Java developers, the release expands the work that can stay on accelerators: calling MLX operations alongside compiled Java kernels, or exchanging results between Nvidia GPUs. These are separate hardware-specific paths; this article examines the release records and implementation descriptions, without a local hardware test.
TornadoVM compiles selected Java bytecode into GPU code at runtime. It complements an existing JVM, handling accelerator memory and task execution while the rest of the application runs normally. A task graph describes the operations to run and their data transfers. That gives the two additions a common integration point, even though their underlying libraries target different hardware.
MLX operations share buffers with Java kernels
The merged MLX implementation describes a provider that launches MLX's Metal kernels on TornadoVM's command queue, using TornadoVM's buffers. Its example places an MLX normalization operation and matrix multiplication between Java kernels compiled at runtime. According to the implementation description, that handoff needs no separate MLX array, result allocation or copy.
That arrangement gives developers a way to combine their own computation with MLX operations inside one graph. The supported argument forms still matter: the provider reports an error when it cannot reproduce an operation exactly, rather than falling back to another implementation. A listed operation should therefore be checked against the shapes and arguments a workload actually uses. The pull request documents that failure behavior explicitly.
NCCL handles the exchange between GPUs
On Nvidia hardware, the NCCL addition addresses a different part of the pipeline: communicating between devices. The implementation supports collective operations, including all-reduce, plus point-to-point transfers on TornadoVM device buffers. Those calls are ordered on each execution plan's CUDA stream alongside its kernels.
The author's example computes gradients, averages them with an in-place all-reduce, then updates weights. The useful consequence is specific: that sequence can exchange its intermediate results through NCCL without copying them back to the host for merging. It doesn't establish a speedup for every Java application. The implementation's test instructions require the NCCL library, and its two-GPU tests need two CUDA GPUs.
Installation still follows the backend
Version 7.3.1 followed on October 15. Its release notes list deployment of the MLX and NCCL modules to Maven Central in the release pipeline. The SDK instructions tell users to match the archive to their JDK and accelerator backend. An OpenCL build alone isn't the configuration described for either of these integrations.
For an evaluation, watch the boundary between operations: whether the MLX provider accepts the required arguments, or whether the NCCL step works with the intended GPU and process layout. Those are the documented integration constraints worth checking before comparing timings. We haven't measured throughput, memory use or compatibility on either path.