Arsitektur JVM

Setiap kali kita menjalankan java Aplikasi, sebuah mesin lengkap terbangun di memori: Java Virtual Machine. JVM inilah yang memuat class dari berkas .class, menyimpan objek di heap, menjaga frame method di stack, mengeksekusi bytecode, dan sekaligus mengelola sampah memori lewat garbage collector. Chapter Cara Kerja Java di Section sebelumnya telah memperlihatkan alur kompilasi hingga eksekusi; pada Section ini kita membongkar mesinnya lebih dalam, dimulai dari peta arsitektur JVM secara utuh. Pemahaman peta ini menjadi fondasi bagi seluruh chapter berikutnya — mulai dari class loading, heap dan stack, hingga tuning memori.

Peta Besar Arsitektur #

Arsitektur HotSpot JVM — implementasi JVM yang dipakai Temurin dan mayoritas distribusi Java — dapat digambar menjadi tiga subsistem besar yang bekerja berurutan, ditopang oleh sekumpulan area data runtime. Diagram berikut merangkum alurnya:

Alur kerjanya berjalan begini. Class loader subsystem membaca berkas .class dari disk atau jaringan, memverifikasi keamanannya, lalu menyiapkan representasi internal class di memori. Representasi tersebut tersimpan di runtime data areas — area-area memori yang mencakup heap untuk objek, stack untuk frame method, dan Metaspace untuk metadata class. Terakhir, execution engine mengambil bytecode dari method yang tersimpan lalu mengeksekusinya, baik lewat interpreter maupun JIT compiler. Garbage collector beroperasi di atas heap untuk memungut objek yang sudah tidak terjangkau.

Class Loader Subsystem #

Subsistem pertama bertugas membawa bytecode dari luar ke dalam JVM. Pekerjaannya terbagi tiga fase — loading, linking, dan initialization — yang akan kita bedah tuntas pada Chapter Class Loading. Hasil akhirnya adalah struktur class yang siap dipakai: field static sudah bernilai awal, method sudah dapat dipanggil, dan hierarki class loader sudah terbentuk tiga lapis (bootstrap, platform, application).

Fase linking memuat satu langkah penting bernama bytecode verification. Verifier memeriksa bahwa instruksi tidak melanggar aturan tipe, stack operand tidak meluap, dan lompatan tidak mendarat di tengah-tengah instruksi. Berkat pemeriksaan ini, JVM dapat menjalankan kode yang tidak sepenuhnya dipercaya tanpa membahayakan proses utuh — jaminan yang dibutuhkan sejak era applet dan masih relevan untuk arsitektur plugin modern.

Runtime Data Areas #

Inilah “ruang simpan” JVM yang menjadi panggung utama Section ini. Spesifikasi JVM mendefinisikan lima area utama:

Pemisahan ini punya konsekuensi praktis. Objek hidup di heap dan dikelola otomatis, sedangkan frame stack lahir dan mati mengikuti pemanggilan method — selesai method, frame-nya dibongkar. Ketika frame menumpuk tanpa batas karena rekursi tanpa dasar, JVM melempar StackOverflowError; kita akan menyaksikannya pada Chapter Heap dan Stack. Metadata class pula puna tempat tersendiri bernama Metaspace sejak Java 8 menggantikan PermGen.

Execution Engine dan JIT Bertingkat #

Bytecode bukan bahasa mesin prosesor, sehingga diperlukan penerjemah. Execution engine HotSpot memakai dua mekanisme yang bekerja bergandengan. Pertama, interpreter membaca dan menjalankan instruksi satu per satu sejak program dimulai — startup cepat tanpa waktu kompilasi tambahan. Kedua, Just-In-Time (JIT) compiler mengamati method yang sering dieksekusi (kode panas), lalu mengompilasinya menjadi bahasa mesin asli prosesor sehingga pemanggilan berikutnya berjalan jauh lebih cepat.

JIT HotSpot bekerja bertingkat. Compiler C1 (client) mengompilasi cepat dengan pengoptimalan sedikit — cocok untuk fase pemanasan. Compiler C2 (server) menyusul untuk method yang terbukti sangat sering dipakai, lengkap dengan pengoptimalan agresif seperti inlining dan escape analysis. Mekanisme kombinasi ini disebut tiered compilation dan menjadi default sejak Java 8. Akibatnya, program Java kerap makin cepat setelah berjalan beberapa puluh detik — fenomena pemanasan yang wajib dipahami siapa pun yang mengukur performa.

Menyapa JVM yang Nyata #

Teori di atas bisa kita sambungkan dengan mesin sungguhan yang ada di mesin uji. Program berikut membaca identitas JVM yang sedang menjalankannya:

public class InfoJVM {
    public static void main(String[] args) {
        System.out.println("nama VM      : " + System.getProperty("java.vm.name"));
        System.out.println("versi VM     : " + System.getProperty("java.vm.version"));
        System.out.println("fitur utama  : " + Runtime.version().feature());
        System.out.println("info VM      : " + System.getProperty("java.vm.info"));
        System.out.println("prosesor     : " + Runtime.getRuntime().availableProcessors());
    }
}

Output yang Dihasilkan:

nama VM      : OpenJDK 64-Bit Server VM
versi VM     : 25.0.4.1+1-LTS
fitur utama  : 25
info VM      : mixed mode, sharing
prosesor     : 2

Mari kita telaah baris-baris kode di atas:

1. Baris 3-4 (System.getProperty(...)): membaca property runtime java.vm.name dan java.vm.version dari JVM aktif. Property ini diisi oleh JVM saat startup, bukan oleh compiler, sehingga nilainya menggambarkan mesin yang benar-benar mengeksekusi program.
2. Baris 5 (Runtime.version().feature()): Runtime.version() mengembalikan objek Runtime.Version; method feature() mengambil angka fitur utama — 25 pada JDK 25 LTS.
3. Baris 6 (java.vm.info): ringkasan mode eksekusi. Nilai mixed mode, sharing berarti JVM menggabungkan interpreter dan JIT (mixed) serta memakai class data sharing agar startup lebih cepat.
4. Baris 7 (availableProcessors()): jumlah prosesor yang terlihat JVM, dipakai untuk mengatur jumlah thread compiler dan GC. Nilainya bergantung mesin tempat program berjalan.

Dari sisi command line, bendera -XX:+PrintCommandLineFlags memaksa JVM mencetak bendera yang aktif — termasuk bukti bahwa G1 menjadi garbage collector bawaan JDK 25:

java -XX:+PrintCommandLineFlags -version

-XX:InitialHeapSize=67108864 -XX:MaxHeapSize=1073741824 ... -XX:+UseG1GC
openjdk version "25.0.4.1" 2026-08-18 LTS

Angka InitialHeapSize dan MaxHeapSize di atas ditentukan secara ergonomis dari ukuran memori mesin, sehingga nilai Anda akan berbeda bila RAM mesin berbeda; bagian yang stabil adalah UseG1GC yang aktif secara bawaan. Garbage collector ini akan kita sandingkan dengan saudaranya — Serial, Parallel, dan ZGC — pada Chapter Jenis Garbage Collector.

Dengan peta lengkap di tangan, kita siap masuk ke subsistem pertama secara detail: bagaimana sebuah berkas .class berubah menjadi class hidup di dalam JVM melalui proses loading, linking, dan initialization — itulah pokok bahasan Chapter Class Loading berikutnya.

Referensi #

• Oracle: The Java Virtual Machine Specification (Java SE 25)
• Oracle JDK 25 Documentation
• OpenJDK HotSpot Group
• Oracle: Learn Java — JVM

public class InfoJVM {
    public static void main(String[] args) {
        System.out.println("nama VM      : " + System.getProperty("java.vm.name"));
        System.out.println("versi VM     : " + System.getProperty("java.vm.version"));
        System.out.println("fitur utama  : " + Runtime.version().feature());
        System.out.println("info VM      : " + System.getProperty("java.vm.info"));
        System.out.println("prosesor     : " + Runtime.getRuntime().availableProcessors());
    }
}