Cloud Parts

Java Virtual Machine (HotSpot)

The abstract machine that runs Java bytecode, and OpenJDK’s HotSpot, the implementation most people use: an interpreter, two JIT compilers and a choice of garbage collectors behind Java, Scala, Clojure and other languages.

What it is
Runtime virtual machines
Type
Open source
Made by
Oracle and the OpenJDK community
License
GPLv2 with the Classpath Exception (OpenJDK)
Facts checked
8 October 2026
Website Source code

What it is

The JVM is defined by a specification, not by one program. It knows nothing of the Java language, only of the class file format: bytecode for a stack machine plus a symbol table. Any language that can be expressed as valid class files can run on it, which is how Scala and Clojure share Java’s libraries. The specification also leaves the garbage collector open: objects live on a heap shared by all threads and are “never explicitly deallocated”, but how the heap is collected is up to the implementation.

HotSpot, the JVM in OpenJDK, has a class loader, a bytecode interpreter, two or three JIT compilers and a handful of garbage collectors, in more than 1.2 million lines of C and C++. A method starts out interpreted. With tiered compilation, on by default, methods that run often are compiled first by the client compiler into code that records a profile of itself, then by the server compiler, which uses that profile to optimise. For memory, G1 is the default collector on most machines; ZGC keeps pauses under a millisecond at some cost in throughput, and the serial collector suits heaps up to about 100 MB. Since Java 21, virtual threads let a server run one cheap thread per request instead of one OS thread.

Start-up is the JVM’s weak spot, and two projects attack it. JDK 24 can record which classes an app loads and links in a training run and keep them, already loaded and linked, in an ahead-of-time cache; Spring PetClinic then starts in 2.604 seconds instead of 4.486. GraalVM Native Image goes all the way: it analyses which code is reachable and compiles the app ahead of time into a native executable that starts in milliseconds, as long as every class it needs is known at build time.

Why teams pick it

  • Compile once: the same class files run on every operating system and CPU that has a JVM
  • A profile-guided JIT: tiered compilation starts fast with the client compiler and reaches peak speed with the server compiler
  • A choice of garbage collectors, from serial for small heaps to G1 by default and ZGC for sub-millisecond pauses
  • One runtime for many languages: Java, Scala and Clojure share libraries, and invokedynamic (Java 7) helps dynamically typed languages run efficiently
  • Virtual threads (Java 21) make thread-per-request servers cheap without rewriting code as callbacks

Watch out for

  • Slow start and warm-up: a large app loads and links tens of thousands of classes (about 21,000 for Spring PetClinic) and runs interpreted until the JIT catches up
  • Memory overhead beyond the heap: tiered compilation alone multiplies the default code cache size by five
  • Ahead-of-time compilation with Native Image assumes a closed world, so reflection and dynamic class loading need metadata at build time
  • Low-pause collectors cost throughput: ZGC trades some throughput for its sub-millisecond pauses

Alternatives

What all runtime virtual machines have in common →
.NET runtime (CLR)Open sourceMicrosoft’s open-source runtime for C#, F# and Visual Basic: the Common Language Runtime loads intermediate language, compiles it with a tiered JIT or ahead of time, and manages memory with a generational garbage collector.BEAM (Erlang virtual machine)Open sourceThe virtual machine in Erlang/OTP that runs Erlang and Elixir: millions of lightweight processes, each with its own heap and garbage collection, preemptively scheduled across all cores, with code that can be replaced while the system runs.

How it fits with other technologies

Pick a collector, then build and use an ahead-of-time cache (JDK 24 or later) · bash

# run with ZGC, the low-pause collector, and a 16 GB heap
java -XX:+UseZGC -Xmx16g -cp app.jar com.example.App

# 1. training run: record which classes the app loads and links
java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar com.example.App
# 2. create the cache from that record (doesn't run the app)
java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar
# 3. production runs start with those classes already loaded and linked
java -XX:AOTCache=app.aot -cp app.jar com.example.App

See it in a real stack

No architecture uses Java Virtual Machine (HotSpot) yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from1996–2025

Sun designed the Java platform for networked consumer devices, where “compiled code had to survive transport across networks, operate on any client, and assure the client that it was safe to run.” The answer was a virtual machine with its own instruction set and strict checks on the code it loads. The first prototype JVM ran on a handheld device that resembled a PDA, the HotJava browser showed programs downloaded with web pages, and JDK 1.0 shipped on 23 January 1996.

Early JVMs were slow. In 1997 Sun bought Animorphic (Longview Technologies), founded by Urs Hölzle and Lars Bak from Sun’s cancelled Self project, whose Strongtalk virtual machine compiled only the code that ran often. Sun built HotSpot on that work, with a new optimising server compiler started by Cliff Click, and released it on 27 April 1999, claiming it doubled the performance of Java 2.

On 13 November 2006 Sun released HotSpot and the Java compiler under the GPL, the start of OpenJDK, which has been the reference implementation of Java SE since version 7. Oracle took over when it bought Sun. Since then the JVM has kept growing in two directions: more languages (invokedynamic for dynamic languages in JDK 7, July 2011) and new runtime features such as virtual threads (JDK 21, September 2023) and an ahead-of-time class cache (JDK 24, March 2025).

Why it’s built this way

A portable bytecode with strict checks
Code arrived over the network from strangers. The JVM imposes strong syntactic and structural constraints on class files so it can refuse unsafe code before running it, on any host.
Interpret first, compile the hot spots
HotSpot’s name says it: profile the running program and spend compiler time only where it runs most. Tiered compilation later added a quick first compiler so start-up no longer had to wait for the server compiler.
Leave the garbage collector unspecified
The specification “assumes no particular type of automatic storage management”, so HotSpot could add new collectors, from serial to G1 and ZGC, without changing a line of anyone’s bytecode.
User-defined class loaders
Besides the JVM’s own bootstrap loader, applications can supply their own class loaders to change how classes are found and loaded, which lets servers and plugins load code at run time.

Timeline

  1. 1996

    JDK 1.0 released on 23 January

  2. 1997

    Sun buys Animorphic, makers of the Strongtalk VM

  3. 1999

    HotSpot performance engine released on 27 April

  4. 2006

    Sun releases HotSpot under the GPL on 13 November

  5. 2011

    JDK 7 adds invokedynamic for dynamic languages

  6. 2023

    JDK 21 ships virtual threads

  7. 2025

    JDK 24 adds the ahead-of-time class cache

Sources14 · facts checked 8 October 2026

Improve this page on GitHub