Why the JVM Can Run Cross‑Platform and an In‑Depth Look at Its Internal Architecture

The Java Virtual Machine (JVM) enables the "write once, run anywhere" promise by shielding Java bytecode from underlying operating‑system specifics; a diagram illustrates this abstraction.

JVM Organization

The JVM consists of several subsystems: the class‑loader subsystem (responsible for loading .class files into the runtime), the runtime data area (where the actual program logic executes), the heap, the stack, the method area (also called Metaspace in JDK 8+), and the program counter register.

Class‑Loader Subsystem

It loads class files into the runtime data area, preparing them for execution.

Runtime Data Area

Heap – shared by all threads, stores objects created with new and arrays.

Stack – thread‑local, follows LIFO order and contains local variables, operand stack, dynamic linking information, and method return addresses.

Method Area (Metaspace) – stores class metadata, static variables, and constants; shared by all threads.

Program Counter (PC) – records the current bytecode offset for each thread, enabling correct resumption after context switches.

Bytecode Execution Engine

Executes bytecode line by line and triggers garbage collection when needed.

Code Example

package com.jvm;
public class JvmRunner {
    public static final int month = 5;
    public int show(){
        int one = 10;
        int two = 11;
        int result = one + two;
        return result;
    }
    public static void main(String[] args){
        JvmRunner jvmRunner = new JvmRunner();
        jvmRunner.show();
    }
}

After compiling, the class file is decompiled (illustrated by diagrams) to show how the show method uses stack frames, local variables, and the operand stack.

Heap Structure

The heap is divided into the Young Generation (Eden, Survivor spaces S0/S1) and the Old Generation. Small, short‑lived objects are allocated in Eden; surviving objects are promoted to Survivor spaces and eventually to the Old Generation based on age thresholds.

Object Allocation Process

Pointer bumping – sequential allocation in a contiguous region.

Free‑list – finds suitable gaps in a fragmented heap, similar to parking slots.

Concurrency Controls

CAS (Compare‑And‑Swap) for lock‑free updates.

Thread‑Local Allocation Buffers (TLAB) – each thread gets a private chunk of the heap to reduce contention; enabled by default in JDK 7+.

Object Header

The object header (mark word) stores identity hash code, lock information, garbage‑collection age, and a reference to the class metadata (Klass pointer).

Pointer Compression

Compressed Oops reduce memory footprint on 64‑bit JVMs by using 32‑bit offsets for object references, allowing up to ~32 GB heap size while keeping pointer size small. Compression is disabled for heaps larger than 32 GB or when the -XX:-UseCompressedOops flag is set.

Where Objects End Up After Allocation

Eden (young generation) for most new objects.

Old Generation for large objects or those that survive many GC cycles.

Stack (via escape analysis) when the JVM determines the object does not escape the method.

Parameters Controlling Allocation

-XX:PretenureSizeThreshold – size threshold for direct allocation into the Old Generation.

-XX:MaxTenuringThreshold – maximum age before promotion.

-XX:TargetSurvivorRatio – controls when objects are moved to the Old Generation based on Survivor space occupancy.

Garbage Collection and Promotion Policies

When the Old Generation lacks sufficient contiguous space, the JVM may trigger a Full GC; otherwise, Minor GCs handle Young Generation reclamation and promotion.