JVM

34 lessons · free to read

How Java really runs: class loading, memory areas, garbage collection and the JIT.

Take this course in the learning hub

Lessons

• What the JVM actually isA program that reads bytecode and turns it into fast machine code on whatever box it lands on.
• From source to bytecodeOpen the class file javac produced and meet the little stack machine underneath Java.
• Class loading and the loadersClasses arrive lazily, in three steps, through a chain of loaders that always ask their parent first.
• Where the JVM puts thingsHeap, stacks, metaspace and code cache - four separate pots, each with its own way of running out.
• What an object really costsEvery object carries a 12 byte header, and the total is rounded up to a multiple of eight.
• Garbage collection basicsNothing is freed because you asked. Objects go when no living code can reach them any more.
• Generational collectionMost objects die young, so the collector checks the newest ones far more often than the rest.
• GC roots and reachabilityThe collector starts from a fixed set of roots and walks. Whatever it cannot reach is garbage.
• G1 and ZGCG1 balances throughput against pause time. ZGC trades some throughput for pauses under a millisecond.
• Leaks in a collected languageA collector cannot free what your code still points at. That is every Java memory leak, in one line.
• OutOfMemoryError vs StackOverflowTwo errors, two completely different pots of memory, and two completely different fixes.
• JIT compilation and warm-upCode starts interpreted, gets compiled once it is proven hot, and only then runs at full speed.
• Escape analysis and inliningThe JIT inlines small methods, then proves some objects never escape and skips allocating them entirely.
• Flags worth knowingA short list of JVM flags that genuinely earn their place in a production start command.
• Heap dumps and thread dumpsTwo snapshots answer most production questions: what is sitting in memory, and what is stuck.
• Java Flight RecorderA profiler built into the JVM itself, cheap enough to leave switched on in production.
• Startup, shutdown and exit codesmain() returning is not the end. The JVM runs until the last non-daemon thread stops.
• How a method call is dispatchedFive kinds of call site, five opcodes, and one vtable lookup that picks the body at run time.
• The string pool and interningLiterals are shared, anything built at run time is not, and that is the whole == confusion.
• Strong, soft, weak and phantomFour ways to hold an object, from never collected to a signal that it has already gone.
• TLABs: allocation is a pointer bumpEach thread owns a private slab of eden, so new is an add and a store, with no lock anywhere.
• Safepoints and stop-the-world pausesA pause cannot begin until every thread has reached a point where its state can be read.
• Reading a GC logThree numbers answer nearly every question: pause length, pause frequency, and live set after a full GC.
• Native memory: why RSS beats -XmxThe heap is one pot among several. A container kills you on the total, not on -Xmx.
• The JVM inside a containerModern JVMs read the cgroup limits, so the defaults are sane - until someone hardcodes -Xmx.
• Class data sharing and startupShip a pre-parsed archive of your classes and the JVM maps it in instead of reading the jars.
• The Java Memory Model and happens-beforeWhy a program without synchronisation can be wrong even on one core.
• False sharing and memory layoutTwo threads touching different fields can still fight over the same cache line.
• Tuning GC from evidence, not folkloreAllocation rate, live set and pause targets - the three numbers that decide everything.
• Profiling: finding where the time really goesSampling profilers, safepoint bias, and reading a flame graph.
• When the JIT gives up: deoptimisationSpeculative optimisation, and the cliff when the speculation turns out wrong.
• Reading a thread dump properlyDeadlock, live-lock, pool exhaustion and blocking - each has a distinct signature.
• When the heap is fine and memory still growsMetaspace, direct buffers, thread stacks and the allocator - the memory Xmx does not cover.
• Benchmarking without fooling yourselfDead code elimination, constant folding and warm-up - why hand-rolled timing lies.