CODExSIMS Systems, made visible

Memory · garbage collection · profiling

Make JVM memory and runtime behavior observable

Memory, garbage collection and profiling inside the Java runtime. Follow a guided path from first principles to the behavior that matters in production.

Choose a path
A Java app allocates across heap regions and off-heap memory; ZGC marks and relocates heap objects while Java Flight Recorder captures the resulting event stream.
  1. 01 Observe the runtime0 of 1 complete JFR · events · profiling
  2. 02 Memory systems0 of 1 complete Heap · off-heap · allocation
  3. 03 Collectors0 of 1 complete ZGC · pauses · concurrency

01 / Pick where to begin

Choose a learning path

3 guides across 3 paths

01 / JFR · events · profiling

Observe the runtime

0 of 1 runs complete

02 / Heap · off-heap · allocation

Memory systems

0 of 1 runs complete

03 / ZGC · pauses · concurrency

Collectors

0 of 1 runs complete
About this collection

The JVM hides a great deal of machinery behind ordinary Java code. Objects move through managed memory, garbage collectors coordinate concurrent work and native allocations can grow outside the heap that most dashboards emphasize. When latency or memory use changes, the useful question is not simply whether the JVM is slow. It is which runtime mechanism changed, what evidence would reveal it and how that mechanism affects the application.

This collection provides a compact path through those internals. Start with Java Flight Recorder to see how low-overhead events become evidence, then examine off-heap memory and ZGC in detail. The guides connect runtime structures to the symptoms engineers actually investigate: allocation pressure, pauses, retained native memory and misleading top-line metrics. They are useful when preparing a profiling plan, interpreting production telemetry or building a mental model before reading JVM implementation documentation. Each guide focuses on observable transitions instead of presenting tuning flags as universal answers.