TornadoVM 7.3.1: Jalankan Java di GPU OpenCL, CUDA, dan Metal

TornadoVM 7.3.1 dirilis 15 Oktober 2026 dan menyediakan SDK siap pakai untuk empat versi JDK sekaligus: 21, 25, 26, dan 27. Framework ini menerjemahkan bytecode Java menjadi kernel yang berjalan di OpenCL, CUDA, atau Metal, sehingga kode Java yang sama bisa dieksekusi di GPU tanpa menulis kernel native terpisah. Arsip unduhannya dipisah per kombinasi JDK dan backend.

TL;DR

• Rilis 7.3.1 menyediakan arsip untuk JDK 21, 25, 26, dan 27.
• Backend yang tersedia: opencl, cuda, metal, dan paket full berisi semuanya.
• Modul tornado-mlx dan tornado-nccl kini dipublikasikan ke Maven Central.
• Verifikasi paling cepat lewat perintah tornado --devices setelah JAVA_HOME diarahkan ke JDK yang cocok.

Apa yang baru di TornadoVM 7.3.1?

Perubahan yang paling berdampak bagi tim build adalah publikasi tornado-mlx dan tornado-nccl ke Maven Central melalui pipeline rilis. Sebelumnya, dua modul itu harus diambil dari repositori proyek atau dibangun sendiri, dan itu membuat integrasi ke build Maven perusahaan menjadi pekerjaan tambahan.

Nomor perubahan tersebut tercatat sebagai pull request 1240 di repositori proyek. Dampaknya sederhana tetapi nyata: dependensi bisa dideklarasikan seperti library Java biasa, dengan resolusi versi dan cache yang dikelola Maven. Untuk tim yang memakai mirror internal, artefak itu kini bisa ikut disinkronkan lewat proses yang sudah ada.

Perubahan kedua adalah kematangan paket SDK. Rilis ini menyediakan arsip terpisah per JDK dan per backend, bukan satu paket besar. Pendekatan itu memotong ukuran unduhan dan mengurangi konflik library, karena setiap arsip hanya membawa komponen yang relevan untuk satu kombinasi.

Perubahan ketiga bersifat operasional: dokumentasi rilis sekarang menuliskan urutan variabel lingkungan yang dibutuhkan, yaitu TORNADOVM_HOME dan PATH, lalu perintah tornado --devices untuk memeriksa perangkat yang terdeteksi. Itu terdengar sepele, tetapi justru langkah pertama yang paling sering gagal ketika seseorang mencoba framework akselerator untuk pertama kali.

JDK mana yang sebaiknya dipakai?

Pilih JDK yang sudah dipakai produksi, bukan yang paling baru. Rilis ini mendukung 21, 25, 26, dan 27, tetapi dukungan kompilasi tidak otomatis berarti setiap kombinasi diuji sama dalam di semua lingkungan.

JDK 21 adalah pilihan paling konservatif karena berstatus LTS dan paling banyak dipakai di server. JDK 25 juga LTS. JDK 26 dan 27 lebih menarik untuk eksperimen karena membawa perubahan pada area runtime yang relevan untuk komputasi vektor, tetapi keduanya bukan pilihan pertama untuk beban kerja yang harus stabil sepanjang tahun.

Yang tidak boleh dilakukan adalah mencampur JDK. Arsip TornadoVM dibuat untuk versi JDK tertentu, dan JAVA_HOME harus menunjuk ke JDK yang sama dengan arsip yang diekstrak. Kalau JAVA_HOME menunjuk ke JDK lain, perintah tornado bisa gagal dengan pesan yang tidak menyebut akar masalahnya, biasanya berupa error saat memuat kelas internal.

Untuk mesin build yang mengelola beberapa proyek, cara paling rapi adalah menyimpan setiap kombinasi di direktori terpisah dan mengaktifkannya lewat skrip, bukan lewat variabel global. Satu proyek, satu JDK, satu TORNADOVM_HOME.

Backend	Target akselerator	Kapan dipilih
opencl	GPU dan akselerator yang mendukung OpenCL	Pilihan paling portabel untuk uji lintas vendor
cuda	GPU NVIDIA	Butuh jalur NVIDIA dengan kontrol lebih dekat ke perangkat
metal	GPU Apple	Mesin macOS berbasis Apple Silicon
full	Semua backend di atas	Mesin pengembangan yang harus menguji beberapa target

Kapan TornadoVM masuk akal dibanding menulis kernel CUDA?

TornadoVM masuk akal ketika logika yang ingin dipercepat sudah berupa Java dan tim tidak ingin memelihara dua basis kode. Kalau kernel sudah ada dalam CUDA dan dirawat tim khusus, menulis ulang ke Java hanya menambah lapisan yang harus di-debug.

Kriteria praktisnya ada tiga. Pertama, beban kerja berbentuk loop padat atas array primitif, karena pola itulah yang bisa dipetakan ke kernel paralel tanpa banyak akal-akalan. Kedua, kode tersebut sudah menjadi panas di profiler, jadi ada bukti bahwa CPU memang menjadi leher botol. Ketiga, tim nyaman membaca log kompilasi, karena kegagalan pemetaan biasanya muncul sebagai pesan dari compiler, bukan sebagai exception Java yang ramah.

Sebaliknya, TornadoVM bukan jawaban untuk semua percepatan. Beban kerja yang didominasi I/O, parsing, atau panggilan jaringan tidak akan membaik karena dipindah ke GPU. Overhead transfer memori bisa lebih besar daripada waktu komputasi yang dihemat, terutama untuk data yang bolak-balik antara heap Java dan memori perangkat.

Ada juga biaya operasional. Setiap backend punya driver dan runtime sendiri. Mesin yang harus mendukung NVIDIA dan Apple Silicon sekaligus perlu dua arsip, dua jalur uji, dan dua set ekspektasi performa. Rilis 7.3.1 mempermudah distribusi lewat paket per kombinasi, tetapi tidak menghapus kenyataan bahwa setiap target tetap harus diuji.

Bagaimana cara memverifikasi backend benar-benar aktif?

Jalankan perintah tornado --devices dan tornado --version setelah mengatur TORNADOVM_HOME serta PATH. Kalau perangkat tidak muncul di daftar, berarti backend tidak terpasang atau driver tidak terdeteksi, apa pun yang tertulis di kode.

Urutan yang dipakai di dokumentasi rilis cukup jelas. Ekstrak arsip, arahkan TORNADOVM_HOME ke direktori hasil ekstrak, tambahkan bin ke PATH, lalu panggil kedua perintah tadi. Di Linux dan macOS, arsip yang dipakai contohnya adalah varian jdk21-opencl, sementara di Windows perintahnya memakai tar yang tersedia sejak Windows 10.

Kesalahan paling umum adalah mengekstrak arsip CUDA di mesin tanpa GPU NVIDIA, lalu menyimpulkan TornadoVM rusak karena perangkat kosong. Itu bukan bug, itu backend yang tidak punya target. Kesalahan kedua adalah menjalankan perintah dengan JAVA_HOME yang menunjuk ke JDK berbeda dari arsip, yang biasanya berujung pada pesan gagal memuat kelas internal.

Setelah perangkat terdeteksi, verifikasi berikutnya adalah menjalankan satu unit test milik proyek. Ini penting karena daftar perangkat hanya membuktikan runtime bisa melihat hardware, bukan bahwa kompilasi kernel berhasil. Kompilasi bisa gagal pada driver tertentu walaupun perangkat terdeteksi.

Apa arti tornado-mlx dan tornado-nccl di Maven Central?

Keduanya adalah modul yang menghubungkan TornadoVM ke library akselerator pihak ketiga, dan sekarang bisa diambil sebagai dependensi Maven biasa. Sebelumnya integrasi seperti ini menuntut langkah build manual yang mudah basi ketika versi library berubah.

Bagi tim yang memakai CI, perubahan ini memangkas satu sumber kegagalan. Build tidak perlu lagi mengunduh artefak dari lokasi khusus atau menjalankan skrip tambahan sebelum kompilasi. Semua dependensi mengikuti resolusi standar, termasuk aturan mirror dan cache yang sudah dikonfigurasi di repositori internal.

Bagi pengguna perorangan, dampaknya lebih kecil tetapi tetap terasa saat mencoba proyek contoh. Repositori contoh yang mendeklarasikan modul tersebut kini bisa dibangun tanpa instruksi tambahan. Halaman rilis resmi menyediakan tautan arsip untuk setiap kombinasi JDK dan backend, sementara dokumentasi proyek menjelaskan model pemrograman serta batasannya.

Apakah TornadoVM menggantikan JIT HotSpot?

Tidak. TornadoVM bekerja di samping JVM, bukan menggantikannya. Kode Java tetap dikompilasi dan dijalankan oleh JVM, sementara bagian yang ditandai untuk akselerasi dipetakan ke kernel dan dieksekusi di perangkat.

Konsekuensinya, keputusan pindah ke GPU tetap keputusan desain, bukan efek samping dari memasang library. Bagian kode yang tidak cocok akan tetap berjalan di CPU, dan itu normal. Yang perlu dihindari adalah asumsi bahwa menambahkan anotasi otomatis mempercepat semuanya.

Praktik yang lebih realistis: ukur versi Java murni lebih dulu, catat waktu eksekusinya, lalu bandingkan setelah bagian panas dipetakan. Tanpa baseline, klaim percepatan tidak bisa dibuktikan, dan tanpa bukti, keputusan memindahkan beban ke GPU hanya menambah kompleksitas tanpa manfaat yang terukur.

Bagaimana cara memetakan kode Java ke GPU?

Caranya dengan menandai metode yang akan dipetakan memakai anotasi paralel milik framework, lalu menjalankan program lewat perintah tornado. Setiap metode yang ditandai akan dikompilasi menjadi kernel saat runtime, dan hasil kompilasi itu disimpan di cache supaya eksekusi berikutnya tidak mengulang proses yang sama.

Karena kompilasi terjadi saat runtime, kesalahan pemetaan baru muncul ketika metode itu benar-benar dipanggil. Ini berbeda dari kompilasi Java biasa yang gagal lebih awal. Konsekuensinya, uji unit harus menyentuh jalur akselerasi, bukan hanya jalur CPU. Kode yang lolos semua tes CPU bisa tetap gagal di GPU kalau tipe data atau pola akses memori tidak didukung backend tersebut.

Pola yang paling sering berhasil adalah loop atas array dengan indeks independen, tanpa alokasi objek di dalam loop, dan tanpa ketergantungan antar iterasi. Begitu ada penulisan ke elemen yang sama dari dua iterasi berbeda, hasilnya tidak lagi deterministik dan framework biasanya menolak memetakannya.

Untuk memulai, pendekatan yang paling murah adalah memilih satu metode panas, memetakannya, lalu membandingkan waktu eksekusi dan hasil keluaran dengan versi asli. Kalau keluaran berbeda, masalahnya di pemetaan. Kalau keluaran sama tetapi lebih lambat, masalahnya di overhead transfer, dan solusinya bukan menambah GPU, melainkan mengurangi data yang berpindah antara host dan perangkat.

Satu hal yang sering terlewat: arsip SDK membawa runtime sendiri, jadi memperbarui TornadoVM tidak otomatis memperbarui driver GPU di mesin. Periksa juga versi driver sebagai bagian dari baseline, karena dua mesin dengan arsip identik bisa memberi hasil berbeda hanya karena driver berbeda. Catat keduanya berdampingan supaya perbandingan performa tetap sah.

FAQ

Apakah TornadoVM 7.3.1 bisa dipakai di Windows?

Bisa. Catatan rilis menyertakan contoh untuk Windows 10 ke atas dengan arsip windows-amd64, dan instruksinya memakai tar yang tersedia sejak Windows 10. Backend yang tersedia tetap bergantung pada hardware dan driver yang terpasang.

Berapa versi JDK yang didukung rilis ini?

Empat versi: JDK 21, 25, 26, dan 27. Setiap versi punya arsip sendiri, jadi unduhan harus disesuaikan dengan JDK yang dipakai dan backend yang ingin dijalankan di mesin tersebut.

Apakah perlu GPU khusus untuk mencoba?

Tidak untuk mencoba instalasi. Perintah tornado --devices tetap bisa dijalankan untuk melihat apakah ada perangkat yang terdeteksi. Untuk menjalankan kernel, dibutuhkan GPU dan driver yang sesuai dengan backend yang dipilih.

Di mana melihat daftar perubahan lengkap?

Daftar perubahan ada di halaman rilis resmi pada repositori proyek, termasuk tautan ke pull request nomor 1240 yang memindahkan publikasi tornado-mlx dan tornado-nccl ke Maven Central.