Skip to main content
OpenJDK is a complex, multi-layered platform that provides a complete Java runtime environment. At its core is the HotSpot Virtual Machine, which handles bytecode execution, memory management, and runtime optimization.

​
Core Components

The OpenJDK architecture consists of several key subsystems that work together to execute Java applications:

Runtime System

Thread management, class loading, and execution control

Memory Management

Heap allocation, garbage collection, and metaspace

Execution Engine

Interpreter and JIT compilation system

Module System

JPMS implementation and module resolution

​
Thread Hierarchy

The HotSpot VM implements a sophisticated thread hierarchy defined in src/hotspot/share/runtime/thread.hpp: 
Thread (base class)
├── JavaThread
│   ├── CompilerThread
│   └── ServiceThread
└── NonJavaThread
    ├── NamedThread
    │   ├── VMThread
    │   ├── ConcurrentGCThread
    │   └── WorkerThread
    ├── WatcherThread
    ├── JfrThreadSampler
    ├── JfrCPUSamplerThread
    └── LogAsyncWriter
All Thread subclasses must be either JavaThread or NonJavaThread. This binary classification simplifies thread identification and management throughout the VM.

​
Thread Execution Sequence

Each thread follows a standardized execution sequence:
  1. Native Entry - Platform-specific entry point (thread_native_entry)
  2. Stack Initialization - Stack setup and OS-level initialization
  3. Handshake - Synchronization with creating thread
  4. Common Entry - Shared entry point (call_run())
  5. Pre-run - Virtual per-thread-type initialization
  6. Run - Main thread logic (virtual method)
  7. Post-run - Virtual per-thread-type tear-down
  8. OS Tear-down - Minimal cleanup and final logging

​
Heap Architecture

OpenJDK supports multiple garbage collector implementations, all inheriting from the CollectedHeap base class defined in src/hotspot/share/gc/shared/collectedHeap.hpp: 
CollectedHeap (abstract base)
├── SerialHeap
├── G1CollectedHeap
├── ParallelScavengeHeap
├── ShenandoahHeap
└── ZCollectedHeap

​
Class Loading and Metadata

The classfile subsystem (src/hotspot/share/classfile/) handles:
  • Class Loading - Parsing and verification of class files
  • Module System - JPMS implementation via ModuleEntry and related classes
  • System Dictionary - Class lookup and resolution
  • Class Linking - Symbol resolution and verification

​
Object Representation

Classes are represented internally using the Klass hierarchy (src/hotspot/share/oops/):
  • Klass - Base metadata class
  • InstanceKlass - Represents Java classes
  • ArrayKlass - Base for array types
    • TypeArrayKlass - Primitive arrays
    • ObjArrayKlass - Object arrays
  • Specialized variants: InstanceMirrorKlass, InstanceRefKlass, InstanceStackChunkKlass
The “oops” directory name stands for “ordinary object pointers” and contains the fundamental object and metadata representations used throughout HotSpot.

​
Interpreter System

HotSpot includes two interpreter implementations (src/hotspot/share/interpreter/):

​
Template Interpreter

The primary interpreter that generates platform-specific assembly code at VM startup. Key components:
  • templateTable - Bytecode interpretation logic
  • templateInterpreter - Runtime frame management
  • bytecodes - Bytecode definitions and utilities

​
Zero Interpreter

A portable C++ fallback interpreter for platforms without template interpreter support:
  • bytecodeInterpreter - C++ bytecode interpretation
  • zeroInterpreter - Frame management

​
Compiler Integration

The VM integrates multiple compilation tiers through the AbstractCompiler interface:
  • C1 Compiler - Client compiler for fast compilation
  • C2 Compiler - Server compiler for peak performance
  • JVMCI - JVM Compiler Interface for Graal and other compilers
Compilation is managed by CompilerThread instances that process methods from a compilation queue.

​
Memory Regions

The VM manages several distinct memory regions:
RegionPurposeLocation
HeapJava objectsManaged by GC
MetaspaceClass metadataNative memory
Code CacheJIT compiled codeNative memory
Thread StacksExecution framesPer-thread native memory
Native MemoryVM internalsOS allocation

​
Services and Monitoring

The src/hotspot/share/services/ subsystem provides:
  • JMX Integration - Management beans and monitoring
  • Memory Pools - Per-region memory tracking
  • GC Managers - Garbage collection monitoring
  • Thread Monitoring - CPU time and contention tracking

​
Platform Abstraction

Platform-specific code is isolated in OS-specific directories:
  • src/hotspot/os/linux/ - Linux implementation
  • src/hotspot/os/windows/ - Windows implementation
  • src/hotspot/os/bsd/ - BSD variants
  • src/hotspot/cpu/x86/ - x86/x64 architecture
  • src/hotspot/cpu/aarch64/ - ARM 64-bit
The os subsystem provides abstractions for threading, memory management, and synchronization primitives.

​
Next Steps

HotSpot VM

Deep dive into HotSpot internals

Garbage Collection

GC algorithms and implementations

JIT Compilation

C1, C2, and Graal compilers

Module System

JPMS architecture and implementation

Build docs developers (and LLMs) love

Get started for freeTalk to us