JVM

Bytecode is a compact, platform-neutral instruction set for an abstract machine, stored in .class files. The compiler targets that abstract machine instead of a real CPU, so one compiled artifact runs on any JVM, and the JVM can verify it before running it.

You gain millisecond startup, immediate peak-ish performance, and a much smaller memory footprint with no compiler or class loading at runtime. You give up profile-guided peak throughput, runtime dynamism such as unconstrained reflection, and fast builds.

Order: load, verify, prepare, resolve, initialize, interpret, profile, compile. The class loader subsystem owns the first five (loading through running the static initializer); the execution engine owns the last three (interpreting bytecode, gathering profile counters, and JIT-compiling hot methods into native code).

Class loader subsystem: finds class files and loads, links (verify, prepare, resolve) and initializes types. Runtime data areas: heap, per-thread stacks and program counters, class-metadata area, code cache. Execution engine: interpreter, JIT compiler and garbage collector, which actually run and maintain the code.

Each bytecode costs decode plus an indirect dispatch on top of its actual work, values shuttle through the operand stack instead of registers, and nothing is optimized across instruction boundaries. The interpreter is kept because it starts instantly, costs no compile time for cold code, and is the fallback when compiled code must be abandoned.

It is allocated in eden. Each young collection copies the still-live object into the currently empty survivor space and increments its age. After surviving enough collections (age reaching the tenuring threshold) it is copied into the old generation instead — that copy is called promotion.

The heap is shared by all threads and split into a young generation and an old generation. Young holds eden, where new objects are created, plus two survivor spaces holding objects that survived recent collections. Old holds objects that survived long enough to be promoted.

Metaspace holds per-class runtime metadata: type structures, method bytecode, runtime constant pools, field and method descriptors, dispatch tables. It lives in native OS memory, so it grows on demand instead of competing for a fixed slice of the heap.

Every JVM thread gets its own stack, created with the thread. Each method invocation pushes one frame holding that call's local variables and working values; returning pops it. Stacks are private to their thread and disappear when the thread ends.

A TLAB is a private chunk of the young space handed to one thread. Inside it the thread allocates by advancing a pointer, with no lock and no atomic instruction. Only buffer refills and oversized objects touch the shared heap.

Mark: trace from the roots and flag every reachable object. Sweep: walk the heap and return every unflagged object's space to a free list. Nothing moves, so surviving objects stay put and the reclaimed gaps between them leave the heap fragmented.

HotSpot's simplest collector: one GC thread, and every collection stops all application threads. The young generation is collected by copying live objects into a survivor space; the old generation by a mark-compact pass. Enable it with -XX:+UseSerialGC.

A stop-the-world pause is an interval where the JVM suspends every application thread so the runtime can do work that needs a stable view of the heap and of thread state — for example scanning thread stacks for references. Application code makes no progress for the duration.

White means not yet reached, gray means reached but its outgoing references not yet scanned, black means reached and fully scanned. When no gray objects remain, tracing is complete: everything reachable is black and every remaining white object is unreachable and can be reclaimed.

G1 tracks how much live data each region holds. For a given pause it collects all young regions plus, in mixed collections, the old regions with the least live data - the most garbage - because evacuation cost scales with live bytes, so those regions give the most free space per millisecond spent.

Three built-in loaders: the bootstrap loader (native, no parent) defines the core runtime classes; the platform loader defines the remaining JDK modules; the application (system) loader defines your code from the class path and module path. They form a chain: application -> platform -> bootstrap.

A class loader is asked for a binary name and produces the class's bytes (usually a .class file on the classpath, but any source works). The JVM parses that byte stream, loads the superclass and superinterfaces first, and creates a runtime type: internal class metadata plus a java.lang.Class object on the heap.

It first checks whether it has already loaded that name; if not, it asks its parent, which asks its own parent, all the way up to the bootstrap loader. Only if every ancestor fails does it try to find the bytes itself. Core JDK types are therefore always defined by the bootstrap loader.

No. A runtime type is identified by the pair (fully-qualified name, defining class loader). Load the same class file with two different loaders and you get two distinct, non-interchangeable types, each with its own Class object.

Extend java.lang.ClassLoader, override findClass(name): fetch the bytes yourself, then call the protected defineClass(name, bytes, 0, len), which asks the VM to parse them into a runtime Class. Leave loadClass alone so parent delegation still works.

Source is compiled ahead of time into bytecode. At runtime the JVM first interprets that bytecode, counts how often each method runs, and once a method is hot a just-in-time compiler turns it into native machine code used from then on. Both modes run side by side.

The JVM first interprets bytecode while counting execution. Each method has counters for how often it is called and how often its loops iterate; when a counter crosses a threshold the JVM compiles that method to optimized native code, so hot paths speed up after warm-up.

C1 compiles fast and optimizes lightly, so code becomes native quickly with modest peak speed. C2 optimizes aggressively and compiles slowly, giving the best steady-state throughput. A single JVM uses both: C1 for quick warmup and profiling, C2 for the hottest methods.

The JIT compiles using the profile gathered so far — e.g. only one receiver type seen, this branch never taken — and replaces the unproven path with an uncommon trap. If the assumption breaks, the trap fires, the runtime deoptimizes that frame back to the interpreter at the same bytecode, and the method is later recompiled without the failed assumption.

An invocation counter (incremented on method entry) and a back-edge counter (incremented on every backward branch, i.e. loop iteration). Invocations alone miss long-running loops in rarely called methods. Crossing a threshold files an asynchronous compilation request; back-edge overflow requests on-stack replacement.

Reads and writes are atomic for object references and for every primitive type except long and double. Non-volatile long and double accesses may be split into two 32-bit halves, so a reader can see a mix of two values. Declaring them volatile makes them atomic again.

Final fields are frozen when the constructor returns. Any thread that later obtains the object's reference sees those fields correctly initialized, with no lock and no volatile on the reader's side, provided the reference did not escape during construction.

Program order within a thread; unlocking a monitor before any later lock of it; a volatile write before any later read of that field; Thread.start before the new thread's actions; a thread's actions before a successful join; interrupt before the interrupt is detected; constructor end before the finalizer; default writes before any thread starts; plus transitivity.

volatile: visibility and ordering for that field plus single read/write atomicity, but no compound atomicity. synchronized: all three, only for threads taking the same lock. final: a one-time publication freeze at constructor end, nothing else. Atomics/VarHandle: single-variable atomicity, never multi-variable.

Because compilers and CPUs freely transform code, the language must state which value a read of a shared field may legally return. The memory model is that contract: it bounds optimization and reordering so one program behaves the same on every CPU.

[3.216s] is uptime, info the log level, gc the tag, GC(7) the collection's id. It was a young pause caused by G1 evacuation. Heap used went 512M before to 96M after, of 1024M total, taking 14.221 ms stop-the-world.

On JDK 9 and later the default is G1 on any server-class machine (roughly two or more CPUs and enough memory). On a smaller machine or container, JVM ergonomics falls back to Serial. On JDK 8 the default was the Parallel collector.

-Xms is the initial heap size the JVM commits at startup; -Xmx is the maximum it may grow to. With neither set, HotSpot defaults to roughly 1/64 of available memory for initial and 1/4 for maximum, reading the container limit rather than host RAM when running under one.

Use the unified logging flag -Xlog. Its four colon-separated parts are selectors, output, decorators, output options: -Xlog:gc*:file=gc.log:time,uptime,level,tags:filecount=10,filesize=20M. It replaced -XX:+PrintGCDetails and -Xloggc, and is cheap enough to leave on in production.

Young collections log Pause Young, G1's mixed ones Pause Young (Mixed) (young plus some old regions), and full ones Pause Full, which collects and compacts the whole heap in one long stop. Under G1 or a concurrent collector, a Full GC signals the concurrent machinery failed to keep up.