Skip to content
JVM Atlas

Reference

Glossary

84 terms, each explained simply and in depth. Terms underlined with dots anywhere on the site open these explanations in place.

<clinit>also: class initialization method

The hidden method the compiler builds from a class's static blocks and static field initializers.

Why it exists

It gives static initialization ordinary bytecode that the JVM can run under its initialization rules.

Sources

<init>also: instance initialization method, constructor

The bytecode name of a constructor.

Why it exists

It separates allocation (new) from construction, while the verifier guarantees objects are initialized before use.

Sources

Application class loaderalso: System class loader

The loader for your own classes and the libraries on your class path.

Why it exists

Applications need a default loader that knows where their classes are.

Sources

Bootstrap class loader

The JVM's built-in loader for the core classes such as Object and String. Java code sees it as null.

Why it exists

Someone has to load the classes that class loaders themselves are made of.

Sources

Bytecode

The compact instruction language inside .class files, designed for the JVM rather than for any particular CPU.

Why it exists

A portable, verifiable, compact format that any JVM can interpret or compile to native code.

Misconception: The CPU executes bytecode.

CPUs execute only native machine code. Bytecode is interpreted by machine-code templates or compiled to machine code by the JIT.

Sources

C1also: client compiler

HotSpot's fast compiler.

Why it exists

To get hot code out of the interpreter quickly.

Sources

C2also: server compiler, opto

HotSpot's thorough compiler, producing the fastest code.

Why it exists

Peak performance for the code that dominates run time.

Sources

Class data sharing (CDS)

A start-up shortcut: the JVM maps pre-processed core classes from an archive file instead of loading them one by one.

Why it exists

Start-up time and memory: loading hundreds of classes from scratch on every launch is wasteful.

Sources

Class file

The compiled form of one Java class: its name, fields, methods and their bytecode.

Why it exists

A stable, documented contract between any compiler and any JVM.

Sources

Class loader

A part of the JVM, or a Java object, that finds the bytes of a class and hands them to the JVM.

Why it exists

To load classes from anywhere (files, JARs, modules, networks, memory) and to isolate groups of classes from each other.

Sources

Class unloading

Removing classes from memory, possible only together with the class loader that loaded them.

Why it exists

Long-running programs that load code dynamically must eventually free the metadata of code no longer used.

Sources

Code cache

The memory where the JVM keeps machine code it generated.

Why it exists

Generated code needs executable memory managed separately from the heap.

Sources

Compressed oops

A memory-saving trick: object references are stored in 4 bytes instead of 8.

Why it exists

Smaller references mean smaller objects and better cache use.

Misconception: A Java reference is the memory address of the object.

It may be an encoded 32-bit value, and moving collectors change addresses while the program runs.

Sources

Constant pool

A numbered table in each class file listing the names and constants the class's code uses.

Why it exists

Sharing names and constants in one table keeps bytecode small and lets references stay symbolic until run time.

Sources

Defining loader

The class loader that actually created a class from its bytes. It is part of the class's identity.

Why it exists

Identity per loader makes isolation possible: two plugins can each have their own version of a class.

Misconception: Classes with the same fully qualified name are always the same class.

Only if the same loader defined them; otherwise casting between them fails with ClassCastException.

Sources

Deoptimization

Falling back from optimized code to the interpreter when an assumption turns out wrong.

Why it exists

It makes speculative optimization safe.

Sources

Dynamic linking

Each frame knows which class's constant table to use, so names in its code can be looked up while running.

Why it exists

Method and field references are bound at run time, not at compile time.

Sources

Eden

Where new objects are born.

Why it exists

A dedicated nursery makes allocation simple and collection of short-lived objects cheap.

Sources

Escape analysis

The compiler checks whether an object ever leaves a method; if not, it may not need a real heap object at all.

Why it exists

Idiomatic Java creates many short-lived helper objects; removing them is a large win.

Misconception: Every `new` creates an object in the heap.

In compiled code, objects that do not escape may never be allocated.

Sources

Foreign Function & Memory API

A modern Java API for calling C functions and using off-heap memory without writing C glue code.

Why it exists

JNI is verbose and error-prone; FFM is safer and needs no native code of your own.

Sources

Framealso: stack frame

The workspace of one method call: its local variables and a scratch stack.

Why it exists

Each invocation needs its own state, separate from other calls of the same method.

Sources

G1 (Garbage-First)

The default garbage collector, which divides the heap into regions and cleans the most wasteful ones first.

Why it exists

A balanced default: good throughput with predictable pauses.

Sources

G1 region

One of many equal-sized blocks the G1 collector divides the heap into.

Why it exists

Regions let G1 collect a chosen subset of the heap, the regions with the most garbage, to meet pause-time goals.

Sources

Garbage collection

Automatic cleanup: finding objects nothing refers to any more and reusing their memory.

Why it exists

Manual memory management causes leaks, dangling pointers and double frees.

Misconception: Objects are freed as soon as they become unreachable.

They become eligible; a later collection reclaims them, or none does before the program ends.

Sources

GC roots

The starting points of the search for live objects: variables in running methods, static fields and a few JVM-held references.

Why it exists

Reachability must start from references the program can definitely use.

Sources

Heap (Java heap)

The shared memory where all objects and arrays live, cleaned up automatically by the garbage collector.

Why it exists

Objects must outlive the method call that creates them and be shareable between threads.

Misconception: The Java heap is the same as the operating system heap used by `malloc`.

They are separate parts of process memory. The JVM manages the Java heap itself; native code uses the C heap.

Sources

Hidden class

A class created at run time that no other code can refer to by name, used behind the scenes for lambdas and frameworks.

Why it exists

Frameworks and language runtimes need to generate classes cheaply and safely without polluting the class namespace.

Sources

HotSpot

The JVM that ships with OpenJDK and most Java downloads. Its name comes from finding the "hot spots" of a program and compiling them.

Why it exists

The specification describes behaviour; somebody has to build a fast, production-quality machine that implements it.

Sources

Humongous object

In G1, an object so big it gets its own run of heap regions.

Why it exists

Copying very large objects during young collections would be expensive.

Sources

Initialization (class)

Running a class's static setup code, once, the first time the class is really used.

Why it exists

Static state must be set up exactly once, at a predictable time, safely across threads.

Misconception: Static initializers run when the program starts.

They run at the class's first active use, which may be late in the program or never.

Sources

Inlining

Copying a small method's body into the place that calls it, so the call disappears.

Why it exists

Removes call overhead and lets the optimizer see caller and callee together.

Sources

Interpreter

The part of the JVM that runs bytecode one instruction at a time, starting immediately.

Why it exists

To run code with no compilation delay and to observe how it behaves.

Sources

javac

The Java compiler. It checks your .java files and turns them into .class files.

Why it exists

To separate checking and translating the language from executing it.

Sources

JDKalso: Java Development Kit

The download developers install: a Java runtime plus tools such as javac, javap and jcmd.

Why it exists

Developers need both a runtime to run programs and tools to build, inspect and diagnose them.

Misconception: JDK, JRE and JVM are three names for the same thing.

The runs bytecode; a runtime (historically the ) is the JVM plus the class library; the JDK adds development tools.

Sources

jimage (lib/modules)

The single file in a modern JDK that contains all the platform's classes.

Why it exists

Faster lookup and a modular, linkable runtime layout.

Sources

JIT compilationalso: just-in-time compilation

Turning frequently used bytecode into native machine code while the program runs.

Why it exists

Interpreting is slow; compiling everything up front is slow to start and lacks run-time knowledge.

Sources

JNI (Java Native Interface)

The standard way for Java and C/C++ code to call each other.

Why it exists

To reach OS services, hardware and existing native libraries from Java.

Sources

JNIEnv

The handle native code receives to talk back to the JVM.

Why it exists

It gives native code a stable, VM-independent way to use Java objects.

Sources

JREalso: Java Runtime Environment

A Java runtime without the developer tools: enough to run Java programs, not to build them.

Why it exists

End users needed to run Java programs without installing developer tools.

Sources

JVMalso: Java Virtual Machine

The engine that runs Java bytecode on a real computer, managing memory and turning bytecode into machine work.

Why it exists

"Write once, run anywhere": one compiled class file behaves the same on every operating system and CPU.

Sources

JVM stack

Each thread's stack of method calls; every call adds a frame on top.

Why it exists

Nested calls need private, short-lived storage that is released automatically on return.

Sources

Linking

Getting a loaded class ready: check it, set up its static fields, and connect its names to real classes and methods.

Why it exists

To make sure a class is safe and complete before its code runs.

Sources

Loading

The first step in using a class: find its compiled bytes and build an internal description of it.

Why it exists

Classes are needed on demand and can come from many sources.

Misconception: Loading a class runs its static initializer.

is a separate, later step with its own triggers.

Sources

Local variable array

The numbered slots holding a method's parameters and local variables.

Why it exists

Fast, indexed storage that the verifier can type-check.

Sources

Machine codealso: native code

Instructions in the language of one particular kind of processor (CPU). It is the only kind of instruction a processor can run by itself.

Why it exists

Processors differ. Bytecode stays the same everywhere, and each JVM produces machine code for the processor it runs on.

Sources

Mark word

The first part of every object's header, holding things like its hash code and age.

Why it exists

It packs frequently needed per-object state into one word.

Sources

Metaspace

HotSpot's memory for class information. It lives outside the Java heap.

Why it exists

Sizing a fixed PermGen inside the heap was a frequent source of OutOfMemoryErrors.

Misconception: Static fields are stored in Metaspace.

In HotSpot static field values live in the java.lang.Class mirror object in the Java heap.

Sources

Method area

Where the JVM keeps what it knows about each class: methods, bytecode, fields and constants.

Why it exists

Class definitions are shared by all objects and threads, so they are stored once.

Sources

Method profile (MethodData)

Statistics the JVM records about a method while it runs: which types and branches it actually sees.

Why it exists

Profile-guided speculation lets C2 optimize for the common case.

Sources

Module

A named group of Java packages that declares what it needs and what it shares, like java.base or java.sql.

Why it exists

Strong encapsulation and reliable configuration for the JDK and for large applications.

Sources

Native library

A file of machine code (.so, .dylib, .dll) that Java can load and call.

Why it exists

Some functionality exists only as native code.

Sources

Native method stack

Stack space for native (C/C++) code called from Java.

Why it exists

Native code follows the platform's C calling convention and needs a conventional stack.

Sources

nmethod

HotSpot's name for one compiled Java method.

Why it exists

Compiled code needs metadata so the GC, deoptimization and stack walking can understand it.

Sources

Object header

Hidden bookkeeping stored at the start of every object.

Why it exists

The JVM needs per-object data for locking, hashing, GC and finding the object's class.

Sources

Old generation

The part of the heap for long-lived objects, cleaned less often.

Why it exists

Long-lived objects should not be copied again and again by young collections.

Sources

On-stack replacement (OSR)

Switching a method that is already running a long loop over to compiled code, mid-loop.

Why it exists

A method called once but looping for a long time (like main) would otherwise never benefit from compilation.

Sources

Operand stack

A small scratch stack in each frame where the JVM puts values while computing.

Why it exists

A stack machine needs no register names, which keeps bytecode compact and portable.

Misconception: Compiled Java code still pushes and pops an operand stack.

The JIT maps stack slots to CPU registers; the operand stack is a model.

Sources

OutOfMemoryError

The error thrown when the JVM cannot get memory it needs.

Why it exists

Memory is finite; the JVM reports exhaustion as an error the application can log or, rarely, handle.

Sources

Parent delegation

The rule that a class loader asks its parent for a class before looking for it itself.

Why it exists

To keep core classes authoritative and to give each loader a consistent view of types.

Misconception: Loaders are always strictly parent-first.

Built-in loaders route by module first, and custom loaders (for example in web containers) may load child-first.

Sources

PC registeralso: program counter

Each thread's bookmark: which bytecode instruction it is executing.

Why it exists

A thread must know where to continue after a call or a context switch.

Sources

Platform class loader

The loader for parts of the Java platform that are not core, such as the database API java.sql.

Why it exists

To load platform modules with fewer privileges than core classes, and to let them be left out of custom runtimes.

Sources

Platform thread

A normal Java thread, backed by one operating-system thread.

Why it exists

It maps Java concurrency directly onto the OS scheduler.

Sources

Preparation

Reserving the static variables of a class and setting them to defaults: 0, false or null.

Why it exists

So every static field has a defined value before any code can observe it.

Sources

Reachability

Whether a program can still get to an object by following references from a root.

Why it exists

Reachability is the precise definition of "no longer needed".

Sources

Reference

A value that points to an object, like p1 pointing to a Person. Copying it copies the pointer, not the object.

Why it exists

Objects live in the heap; variables and fields need a compact way to refer to them.

Sources

Resolution

Looking up what a name in the bytecode really refers to, the first time it is used.

Why it exists

Late binding lets classes be compiled separately and lets the JVM load only what is used.

Sources

Run-time constant pool

The in-memory version of a class's constant table. When code first uses an entry, the JVM looks up what it refers to and remembers the answer.

Why it exists

To support late binding: code is linked to classes and methods only when it actually runs.

Sources

Safepoint

A moment when every Java thread has paused at a known, safe position so the JVM can do maintenance.

Why it exists

Some VM operations need a consistent view of every thread's stack and references.

Sources

Shenandoah

A low-pause garbage collector that moves objects while your program runs.

Why it exists

Low, heap-size-independent pause times.

Sources

Source codealso: source file, .java file

Instructions written by people in a programming language. A Java source file, such as Hello.java, is plain text you can read and edit.

Why it exists

People need a language they can read and reason about; machines need precise instructions. Source code is the human side of that translation.

Sources

StackOverflowError

The error thrown when a thread makes too many nested calls, usually from endless recursion.

Why it exists

To stop runaway recursion safely instead of corrupting memory.

Sources

Stop-the-world pause

A pause during which the application threads wait while the garbage collector works.

Why it exists

Some GC work is simplest and fastest when objects cannot change underneath it.

Sources

Survivor space

A holding area for objects that survived a young collection, until they are old enough to move on.

Why it exists

It filters out medium-lived objects before they reach the expensive old generation.

Sources

Symbolic reference

A reference by name ("the class called Person") instead of by location.

Why it exists

Classes can be compiled separately and evolve independently, as long as the names they use still exist at run time.

Sources

System call

A request from a program to the operating system, such as "read this file".

Why it exists

Only the kernel may access hardware and other processes' resources.

Sources

Template interpreter

HotSpot's interpreter: every bytecode has a ready-made piece of machine code.

Why it exists

It is much faster than a C++ switch loop while staying simple to keep correct.

Sources

Tiered compilation

HotSpot's step-by-step approach: interpret first, then compile quickly, then compile thoroughly.

Why it exists

It combines fast warm-up (C1) with peak performance (C2).

Sources

TLAB (thread-local allocation buffer)

A private slice of the heap that each thread uses to create objects quickly without waiting for other threads.

Why it exists

Allocation is extremely frequent in Java; making it lock-free and cache-friendly is a large performance win.

Sources

Uncommon trap

A tripwire in compiled code that fires when something the compiler did not expect happens.

Why it exists

It lets the compiler omit code for rare paths while keeping exact semantics.

Sources

Verification

A safety check of a class's bytecode before it may run.

Why it exists

Bytecode can come from anywhere; verification lets the JVM run it fast without checking every instruction at run time.

Sources

Virtual memory

The private address space the operating system gives each process, backed by real memory as it is used.

Why it exists

Isolation between processes and flexible use of physical memory.

Sources

Virtual thread

A very lightweight Java thread; millions can exist, sharing a few OS threads.

Why it exists

Thread-per-request code becomes affordable for I/O-heavy servers.

Sources

Young generation

The part of the heap for new objects, cleaned often because most objects die young.

Why it exists

The weak generational hypothesis: most objects become unreachable soon after allocation.

Sources

ZGC

A garbage collector built for very short pauses, even with huge heaps.

Why it exists

Latency-sensitive applications cannot tolerate pauses that grow with heap size.

Sources

JVM Atlas

Explore the machine behind Java programs. A free, open-source atlas of the Java Virtual Machine. Specification baseline: Java SE 25. Implementation details: OpenJDK HotSpot, JDK 25.

MIT licensed · no accounts, no tracking, no backend · your progress stays in your browser.

JVM Atlas is an independent educational project and is not affiliated with or endorsed by Oracle. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.