Skip to main content
The HotSpot VM is Oracle’s high-performance Java Virtual Machine implementation, combining an interpreter with adaptive JIT compilation to provide optimal runtime performance.

​
Architecture Overview

HotSpot is structured around several key subsystems that work together to execute Java bytecode efficiently:

​
Runtime Components

The runtime system manages the fundamental execution environment:
The thread hierarchy in HotSpot (defined in src/hotspot/share/runtime/thread.hpp:71-87):
// Class hierarchy
// - Thread
//   - JavaThread
//     - various subclasses eg CompilerThread, ServiceThread
//   - NonJavaThread
//     - NamedThread
//       - VMThread
//       - ConcurrentGCThread
//       - WorkerThread
//     - WatcherThread
//     - JfrThreadSampler
All Thread subclasses must be either JavaThread or NonJavaThread. The execution sequence includes:
  • thread_native_entry - per-OS native entry point
  • Stack initialization
  • OS-level initialization (signal masks, etc.)
  • Handshake with creating thread
  • this->call_run() - common shared entry point
  • this->pre_run() - virtual per-thread-type initialization
  • this->run() - virtual per-thread-type main logic

​
Memory Management

The Universe class (src/hotspot/share/memory/universe.hpp:48) is a namespace holding known system classes and objects in the VM:
​
_typeArrayKlasses
TypeArrayKlass*[]
Array of klasses for primitive array types (boolean[], byte[], int[], etc.)
​
_objectArrayKlass
ObjArrayKlass*
Klass for object arrays
​
_main_thread_group
OopHandle
Reference to the main thread group object
​
_system_thread_group
OopHandle
Reference to the system thread group object
​
_out_of_memory_errors
OopHandle
Preallocated error objects (no backtrace) for OOM situations
The object heap is allocated and accessed through Universe, with allocation by the interpreter and compiled code done inline and bailing out to scavenge operations when necessary.

​
Garbage Collection

HotSpot provides multiple garbage collector implementations in src/hotspot/share/gc/:

​
Available GC Implementations

Single-threaded stop-the-world collector suitable for small applications.
  • Young generation: Copy collector
  • Old generation: Mark-sweep-compact
  • Best for: Single-processor machines or small heaps

​
JIT Compilation

HotSpot uses adaptive compilation with multiple tiers:

​
Compilation Tiers

​
Tier 0
Interpreter
Initial execution mode, collects profiling data
​
Tier 1
C1 Simple
Client compiler with minimal optimizations
​
Tier 2
C1 Limited Profile
C1 with limited profiling overhead
​
Tier 3
C1 Full Profile
C1 with full profiling for C2
​
Tier 4
C2
Server compiler with aggressive optimizations

​
Compiler Architecture

From src/hotspot/share/compiler/compileBroker.hpp:94-100: 
class CompileQueue : public CHeapObj<mtCompiler> {
 private:
  const char* _name;
  // Compilation tasks are queued for execution
};
The CompileBroker manages compilation requests:
  • Queues compilation tasks based on method hotness
  • Manages compiler threads (C1 and C2)
  • Handles compilation lifecycle and inlining decisions
The C2 compiler (src/hotspot/share/opto/) is a sophisticated optimizing compiler with:
  • Sea-of-nodes IR representation
  • Global value numbering
  • Escape analysis
  • Loop optimizations
  • Intrinsics for performance-critical operations

​
VM Globals and Configuration

VM behavior is controlled through flags defined in src/hotspot/share/runtime/globals.hpp:37-99:

​
Flag Categories

​
product
flag category
Always settable and visible in production builds
​
develop
flag category
Settable only during development, constant in PRODUCT builds
​
DIAGNOSTIC
flag attribute
For VM quality assurance or field diagnosis. Requires -XX:+UnlockDiagnosticVMOptions
​
EXPERIMENTAL
flag attribute
For experimental features. Requires -XX:+UnlockExperimentalVMOptions
​
MANAGEABLE
flag attribute
Dynamically writeable through JMX (HotSpotDiagnosticMXBean API)

​
Object Representation

​
Klass Kinds

From src/hotspot/share/oops/klass.hpp:68-77: 
enum KlassKind : u2 {
  InstanceKlassKind,
  InstanceRefKlassKind,
  InstanceMirrorKlassKind,
  InstanceClassLoaderKlassKind,
  InstanceStackChunkKlassKind,
  TypeArrayKlassKind,
  ObjArrayKlassKind,
  UnknownKlassKind
};
Each klass kind represents a specific type of Java object:
  • InstanceKlassKind: Regular Java class instances
  • InstanceRefKlassKind: Reference objects (WeakReference, etc.)
  • InstanceMirrorKlassKind: java.lang.Class instances
  • TypeArrayKlassKind: Primitive arrays
  • ObjArrayKlassKind: Object arrays

​
Layout Helper

The layout helper is a combined descriptor of object layout:
  • For instances: positive number representing instance size
  • For arrays: negative number with encoded metadata (tag, header size, element type, log2 of element size)

​
JVM Interface Functions

Core JVM functions from src/hotspot/share/include/jvm.h:66-150:

​
Object Operations

JNIEXPORT jint JNICALL
JVM_IHashCode(JNIEnv *env, jobject obj);

JNIEXPORT void JNICALL
JVM_MonitorWait(JNIEnv *env, jobject obj, jlong ms);

JNIEXPORT void JNICALL
JVM_MonitorNotify(JNIEnv *env, jobject obj);

JNIEXPORT jobject JNICALL
JVM_Clone(JNIEnv *env, jobject obj);

​
System Operations

JNIEXPORT jlong JNICALL
JVM_CurrentTimeMillis(JNIEnv *env, jclass ignored);

JNIEXPORT jlong JNICALL
JVM_NanoTime(JNIEnv *env, jclass ignored);

JNIEXPORT void JNICALL
JVM_ArrayCopy(JNIEnv *env, jclass ignored, jobject src, jint src_pos,
              jobject dst, jint dst_pos, jint length);

​
Memory Management

JNIEXPORT void JNICALL
JVM_GC(void);

JNIEXPORT jlong JNICALL
JVM_TotalMemory(void);

JNIEXPORT jlong JNICALL
JVM_FreeMemory(void);

JNIEXPORT jlong JNICALL
JVM_MaxMemory(void);
These JVM_ functions complement the standard JNI support and are used by native libraries in the standard Java API. For example, java.lang.Object uses VM-level functions for monitor wait and notify operations.

​
Thread-Local Allocation Buffers (TLABs)

HotSpot uses TLABs for fast, thread-local allocation:
  • Each thread has a private allocation buffer in Eden
  • Most allocations are satisfied with a simple pointer bump
  • Reduces allocation contention between threads
  • Falls back to slow-path allocation when TLAB is full

​
Safepoints

Safepoints are synchronization points where all Java threads are stopped:
  • Required for operations like GC, deoptimization, biased locking revocation
  • Thread-local polling mechanism for safepoint checks
  • Managed by SafepointMechanism and SafepointSynchronize
  • Threads must reach a safepoint to ensure a consistent heap state

Build docs developers (and LLMs) love

Get started for freeTalk to us