The Need for JVM Knowledge

Many Java developers encounter critical issues in production: systems freezing, becoming unresponsive, or throwing OutOfMemoryError (OOM) exceptions. Debugging garbage collection (GC) problems often feels overwhelming. When deploying new projects, developers frequently rely on default JVM parameters without understanding their implications, leading to performance degradation. Interview questions frequently shift from theoretical concepts to practical troubleshooting—how to tune JVM parameters, resolve GC overhead, or handle OOM scenarios.

Most Java professionals focus heavily on high-level frameworks like Spring, MyBatis, and microservices, but rarely dig deep into the Java Virtual Machine itself. This imbalance can be problematic: while high-level APIs are like mathematical formulas, JVM internals represent the derivation process behind those formulas. Understanding the foundation enables better system design, performance optimization, and problem resolution.

What Architects Consider

System architects constantly ask:

• How can I make the system faster?
• How do I avoid bottlenecks?

A typical job posting for a senior role (targeting high compensation) includes responsibilities such as:

• Optimizing existing system performance, refactoring, and ensuring platform stability
• Making technology decisions based on business scenarios
• Architecting high-concurrency distributed solutions for massive data
• Identifying and mitigating potential system risks
• Analyzing bottlenecks and performing performance tuning

Why Learn JVM?

1. Interview preparation – Major tech companies frequently ask JVM-related questions.
2. Essential for mid/senior developers – Project management and tuning require this knowledge.
3. Engineering excellence – Understanding garbage collection algorithms, JIT compilation, and low-level mechanisms.

Java vs. C++

Java's automatic memory management increases development productivity significantly. However, garbage collection is not a silver bullet. Understanding JVM memory structure and runtime behavior is crucial for designing scalable applications and diagnosing runtime issues. C++ requires manual memory management; while powerful for experts, it risks memory leaks for average developers. Java delegates this responsibility to the JVM, reducing developer workload.

Who Should Study JVM?

• Experienced Java developers aiming for career growth
• Software designers and architects
• System tuning specialists
• JVM enthusiasts and practitioners

Recommended Resources

• Official Documentation: Java SE Specifications
• Recommended Book: Understanding the JVM by Zhou Zhiming (third edition is significantly updated and preferred over the second).

TIOBE Index and Java's Ecosystem

The TIOBE endex reflects language popularity. There is no single "best" language—only the most suitable for a given context. While Python and Go challenge Java's dominance, Java's extensive ecosystem ensures its continued relevance.

Java has evolved into a platform, culture, and community:

• Platform: The JVM runs multiple languages (Groovy, Scala, Kotlin, JRuby).
• Culture: Java is nearly synonymous with open source (Tomcat, Struts, MyBatis, Spring, OpenJDK).
• Community: Largest developer community with countless forums, resources, and open-source projects.

Cross-Platform Language vs. Cross-Platform VM

Java is cross-platform: "write once, run anywhere." The JVM itself is a cross-language platform. Since Java 7, the JVM can run programs written in languages other than Java. The JVM cares only about valid bytecode (class files), not the source language. Any language whose compiler produces correct bytecode can run on the JVM. This means the JVM is language-agnostic—it's not tied exclusively to Java.

Multi-Language Programming

Combining multiple languages on the JVM is a growing trend. For example:

• Parallel processing in Clojure
• Web layer in JRuby/Rails
• Business logic in Java

Each layer uses the most appropriate language, yet they interoperate seamlessly because they all run on the same VM. Features like invokedynamic, java.lang.invoke, and the Nashorn engine push the JVM toward a true multi-language runtime.

How to Master JVM

The best approach to understanding JVM internals is to implement one yourself. Although the JVM is complex, writing a minimal implementation is an excellent educational exercise.

Java History Milestones

• 1990: Green Team (Naughton, Sheridan, Gosling) developed Oak, later renamed Java.
• 1995: Java and HotJava publicly released.
• 1996: JDK 1.0 released.
• 1998: JDK 1.2, introduction of JSP/Servlet/EJB; Java split into J2EE, J2SE, J2ME.
• 2000: JDK 1.3; HotSpot becomes default VM.
• 2002: JDK 1.4; Classic VM retired.
• 2003: Scala and Groovy appear.
• 2004: JDK 1.5 (Java SE 5.0).
• 2006: JDK 6; Java open-sourced as OpenJDK; HotSpot becomes default in OpenJDK.
• 2007: Clojure joins the platform.
• 2008: Oracle acquires BEA, obtaining JRockit.
• 2009: Twitter migrates from Ruby to Scala; Oracle acquires Sun, gaining HotSpot.
• 2010: Oracle plans HotSpot+JRockit integration (HotRockit).
• 2011: JDK 7; G1 collector introduced in update 4.
• 2017: JDK 9; G1 becomes default GC, replacing CMS.
• 2018: IBM open-sources J9 (OpenJ9); Android Java lawsuit; Java EE transferred to Eclipse; JDK 11 (LTS) introduces ZGC.
• 2019: JDK 12 adds Shenandoah GC (from Red Hat).

OpenJDK vs. Oracle JDK

Before JDK 11, Oracle JDK contained some closed-source components absent in OpenJDK. Starting with JDK 11, the codebases are essentially identical; the main difference is the release cadence.

Virtual Machines

Definition

A virtual machine (VM) is software that executes virtual computer instructions. Two categories exist:

• System VMs: Simulate physical hardware (e.g., VirtualBox, VMware), allowing full OS installation.
• Process VMs: Execute single programs (e.g., JVM for Java bytecode).

Java Virtual Machine (JVM)

The JVM executes Java bytecode. It provides:

• Platform independence
• Automatic memory management
• Garbage collection

Core Role: The JVM loads bytecode, verifies it, and either interprets or compiles it into native machine instructions.

Characteristics:

• Write once, run anywhere
• Automatic memory and GC

JVM Position in System Stack

The JVM runs on top of the operating system, not directly on hardware.

JVM Architecture Overview

HotSpot VM uses a hybrid architecture with both an interpreter and a just-in-time (JIT) compiler. This combination allows fast startup (interpreter) and high steady-state performance (JIT). Modern Java performance rivals C/C++.

Java Code Execution Flow

1. Source code → Compiler → Bytecode (.class)
2. Bytecode → Class loader → JVM runtime
3. JVM interprets or JIT-compiles bytecode into native instructions

Any language that can produce valid bytecode can run on the JVM.

Stack-Based vs. Register-Based Architecture

Stack-Based Architecture

• Simpler design, suitable for resource-constrained systems
• No register allocation problems; uses zero-address instructions
• Instructions are smaller; compiler is simpler
• Highly portable; good for cross-platform support

Register-Based Architecture

• Example: x86 instruction set, Android's Dalvik VM
• Tightly coupled with hardware; less portable
• Better performance; fewer instructions per operation
• Typically uses one-, two-, or three-address instructions

Example: Compute 2 + 3

Stack-based (JVM):

iconst_2       // push 2
istore_1
iconst_3       // push 3
istore_2
iload_1
iload_2
iadd           // pop 2 and 3, push result
istore_0       // store 5

8 instrucsions.

Register-based:

mov eax, 2     // set eax to 2
add eax, 3     // add 3 to eax

2 instructions.

Summary

Java chose stack-based design for cross-platform portability. Although register-based architecture offers better performance, Java prioritizes portability and a small instruction set. Even today, with embedded platforms less dominant, the stack architecture remains due to its intrinsic cross-platform advantage.

JVM Lifecycle

Startup

The JVM starts by creating an initial class via the bootstrap class loader.

Execution

• A running JVM executes Java programs.
• It runs until the program terminates.
• Effectively, "running a Java program" means running a JVM process.

Termination

The JVM exits when:

• The program completes normally.
• An unhandled exception or error occurs.
• The operating system terminates the process.
• A thread calls System.exit(), Runtime.exit(), or Runtime.halt() (with security permission).
• JNI Invocation API unloads the VM.

JVM Evolution

Sun Classic VM (1996)

• First commercial Java VM.
• Only interpreter; no JIT; low performance.
• JDK 1.4 removed it.

Exact VM (JDK 1.2)

• Introduced accurate memory management (knows exact data types in memory).
• Hotspot detection and mixed interpreter/JIT mode.
• Short-lived; only on Solaris.

HotSpot VM (Current Standard)

• Originally from Longview Technologies (acquired by Sun in 1997, then Oracle in 2009).
• Default VM since JDK 1.3.
• Dominates the market; used in Oracle JDK and OpenJDK.
• HotSpot refers to its hotspot detection technology: identifies frequently executed code and optimizes it via JIT compilation or stack replacement.
• Balances startup time and peak performance through interpreter/JIT collaboration.

JRockit (BEA → Oracle)

• Server-focused; no interpreter, only JIT.
• Considered the fastest JVM in many benchmarks.
• Features: JRockit Real Time (low latency), Mission Control (monitoring/suite).
• Acquired by Oracle in 2008; features integrated into HotSpot starting JDK 8.

IBM J9

• IBM's enterprise VM; server, desktop, and embedded usage.
• Open-sourced in 2017 as OpenJ9 (Eclipse Foundation).
• Competed with HotSpot.

KVM / CDC-CLDC HotSpot

• Oracle's Java ME VMs.
• KVM (Kilobyte VM) for very low-end devices (sensors, feature phones).
• Now niche due to Android/iOS dominance.

Azul VM

• High-performance VM for Azul's proprietary Vega hardware.
• Manages dozens of CPUs and hundreds of GB RAM; predictable GC.
• Later, Azul released Zing JVM for general x86 hardware.

Liquid VM (BEA)

• Runs directly on hypervisor without OS.
• Implemented OS services (scheduling, file system, networking).
• Discontinued with JRockit.

Apache Harmony

• Open-source JDK 1.5/1.6 compatible implemantation.
• Never gained JCP certification; retired in 2011.
• Its class library code was adopted into Android SDK.

Microsoft JVM

• Built for Internet Explorer 3 Java applets.
• Windows-only, but fastest on that platform.
• Sun sued Microsoft successfully (1997); removed from Windows XP SP3.

Taobao JVM (Alibaba)

• Custom OpenJDK build (AJDK).
• GCIH (GC Invisible Heap): moves long-lived objects off-heap, reduces GC frequency, enables sharing across JVM instances.
• Uses CRC32 intrinsic, PMU hardware profiling, ZenGC for big data.
• Optimized for Intel CPUs; trades compatibility for performance.
• Deployed on Taobao and Tmall, replacing Oracle JVM.

Dalvik VM (Google)

• For Android (not a Java VM—doesn't follow JVM spec).
• Register-based; executes DEX files (converted from .class).
• JIT added in Android 2.2.
• Replaced by ART (Ahead-of-Time compilation) in Android 5.0.

Graal VM (Oracle Labs, 2018)

• Cross-language, full-stack VM on top of HotSpot.
• Supports Java, Scala, Groovy, Kotlin, C, C++, JavaScript, Ruby, Python, R.
• Enables mixed-language interoperability and native library usage.
• Uses Truffle framework for building language interpreters; JIT compilation for high performance.
• Considered a potential successor to HotSpot, but Java ecosystem remains stable.

Summary

JVM memory structures vary by vendor and version. This guide focuses primarily on Oracle HotSpot VM, the most widely used implementation.