02. JVM and Memory

RU | EN | DE

JVM Architecture — Brief Overview

Class Loader Subsystem

JVM loads classes using a system of class loaders that implements a delegation model:

• Bootstrap ClassLoader – loads standard classes from the JDK (rt.jar or JDK modules).
• Extension ClassLoader – loads libraries from the ext directory.
• Application ClassLoader – loads classes from the classpath.
• Users can create a Custom ClassLoader for dynamic loading (e.g., in OSGi, plugins).

Runtime Data Areas

• Heap – area where all objects live.
• Method Area (Metaspace) – contains class meta-information, constant pool.
• JVM Stack – created per thread, contains method call frames.
• Program Counter Register (PC Register) — is a small pointer that stores the number of the next instruction that the thread should execute.
• Native Method Stack – stack for native method calls.

Execution Engine

• Interpreter – step-by-step interpretation of bytecode.
• JIT Compiler (Just-In-Time) – compiles frequently used methods into machine code.
• GC Interface – Execution Engine is closely linked with the garbage collector: it must know when an object is no longer used and correctly free memory.

Delegation Model

Delegation Model (ClassLoader delegation model) — is a mechanism by which the JVM loads classes in a strict top-down order to avoid conflicts and duplication.

When a ClassLoader wants to load a class, it first delegates this task to its parent, and only if the parent didn’t find the class, it loads it itself.

JVM Memory Management

In JVM, memory is divided into several areas, and each has its own role

• Heap
  • This is where object instances are stored.
  • Space is allocated for each object’s fields (data).
  • References to objects are also created, but these references are usually stored in the stack or in fields of other objects on the heap.
• Stack
  • This is where local method variables are stored, including references to objects on the heap.
  • When the method finishes execution, its frame is removed from the stack.
• Metaspace
  • This is where classes and their structure are stored: methods, constants, field information.
  • Does not store object instances themselves

Heap

• Young Generation: o Eden – new objects. o Survivor Spaces (S0/S1) – intermediate zones.
• Old Generation – objects that survived several collections in Young Gen.

Stack

Each thread has its own stack, consisting of method call frames. Each frame stores:

• local method variables,
• operand stack for intermediate calculations,
• reference to the class’s constant pool to use constants and methods of this class.

Metaspace

• What’s stored: information about classes — their metadata, methods, constants, annotations.
• Difference from PermGen: in Java 8+ PermGen was removed, and Metaspace is stored in native memory, not in heap. This allows JVM to dynamically expand space for metadata without a hard limit (if -XX:MaxMetaspaceSize is not set).
• Growth and limits: grows as new classes are loaded; can be limited through JVM parameters (MaxMetaspaceSize, MetaspaceSize).

Off-heap Memory

This is memory allocated outside the standard JVM heap, directly in native memory.

• Examples:
  • ByteBuffer.allocateDirect() — direct buffer for working with native memory, bypassing GC.
  • Native resource pools, caching large data.
• Dangers:
  • JVM doesn’t track this memory, so leaks are possible.
  • Improper memory deallocation (DirectByteBuffer) can lead to OutOfMemoryError even if heap is empty.

Constant pool

Constant Pool — is a special place in class metadata (part of Method Area in JVM), where constants, literals, and references to methods/classes are stored.

That is, constant pool is like a cabinet with ready things, and stack is a desk where you lay them out for work.

Garbage collector (GC)

GC - JVM mechanism that automatically frees memory occupied by objects that no longer have references.

In modern JVMs, one Garbage Collector can use different algorithms for different memory areas:

• Copying — applied in Young Generation. It quickly copies live objects to a new memory area, and everything else is considered garbage.
• Mark-Sweep-Compact — more often applied in Old Generation. First live objects are marked (Mark), then garbage is removed (Sweep), and the remaining are compacted (Compact) to avoid fragmentation.

GC Types

Serial GC

• Uses one thread for all GC phases.
• Suitable for single-threaded applications and small heaps.
• Algorithm: “copying” (in Young Gen) and “mark-sweep-compact” (in Old Gen).
• Parameter: -XX:+UseSerialGC

Parallel GC (Throughput Collector)

• Uses multiple threads for work in Young and Old Gen.
• Goal — maximum throughput, not pause minimization.
• Suitable for server applications without strict latency requirements.
• Parameter: -XX:+UseParallelGC

CMS (Concurrent Mark Sweep) [deprecated]

• Works in parallel with the application (concurrent), reducing stop-the-world pauses.
• Phases: initial mark, concurrent mark, remark, sweep.
• Doesn’t compact memory (may lead to fragmentation).
• Deprecated starting from Java 9 and removed in Java 14
• Parameter: -XX:+UseConcMarkSweepGC

G1 GC (Garbage First)

• Divides heap into many regions.
• Each region can be part of Young or Old Generation.
• GC phases include: Initial Mark, Concurrent Mark, Remark, Cleanup, Copy.
• Works on the principle of “collect the most garbage-filled regions first” (Garbage First).
• Uses predictable pauses and tries not to exceed MaxGCPauseMillis
• Supports incremental, concurrent, and compacting collection of Old Gen.
• G1 maintains statistics on region “usefulness” and selects the most efficient ones for collection.
• Parameter: -XX:+UseG1GC
• Default from Java 9+

ZGC (Z Garbage Collector)

• Supports heaps up to terabytes.
• Works with pauses less than 10 ms, regardless of heap size.
• Fully concurrent (almost all phases execute in parallel with the application).
• Suitable for latency-sensitive systems.
• Parameter: -XX:+UseZGC

Shenandoah

• Similar to ZGC, with emphasis on short pauses.
• Uses concurrent compacting.
• Supported by OpenJDK.
• Parameter: -XX:+UseShenandoahGC

Which GC is Default in Java

Java Version	Default GC
java 8	Parallel GC
java 9+	G1 GC

Some JDKs (e.g., Azul Zulu) may use ZGC or Shenandoah by default if specific latency goals are set

Pauses

• Stop-the-world – during some GC phases, all threads are paused.
• Minor GC – in Young Generation.
• Major/Full GC – in Old Generation, may include Metaspace cleanup.

Performance and Tuning

• -Xms / -Xmx – minimum/maximum heap size.
• -Xss – stack size per thread.
• -Xss – stack size per thread.
• -XX:+PrintGCDetails, -Xlog:gc

JIT (Just-In-Time) compilation

• JVM first interprets bytecode, but frequently executed methods are compiled into native machine code during program execution.
• Allows speeding up execution by avoiding constant interpretation.
• Optimizations
  • Inlining — the method is “embedded” into the calling code to eliminate method call overhead.
  • Escape Analysis — analyzes whether the object leaves the method/thread; if not — the object can be placed on the stack instead of the heap, reducing GC load.

Class Loading and Reflection

Delegation Model

ClassLoader first delegates loading to the parent, and only then tries to load itself.

Custom ClassLoaders

Needed for:

• plugins
• modular systems (OSGi, Spring Boot)
• hot code reloading

Reflection

Reflection allows dynamic work with classes and their members, creating proxies, but slows execution and can violate encapsulation. SecurityManager can restrict such operations.

Reference Types in Java

Strong Reference

• These are ordinary references we use every day.
• As long as there is at least one strong reference to an object — it is not subject to garbage collection.
• For an object to be collected, all strong references to it must be nulled.

Object obj = new Object();

Soft Reference

• Object is deleted only when memory is low.
• Used in caches to not load memory but keep the object if it’s still useful.
• Can get the object via ref.get(), but if GC already deleted it — will return null.

SoftReference<Object> ref = new SoftReference<>(new Object());

Weak Reference

• Object can be collected immediately, even if only weak references to it remain.
• Used for implementing structures with auto-deletion (e.g., WeakHashMap).
• Often applied when the object should be available “as long as someone needs it”.

WeakReference<Object> ref = new WeakReference<>(new Object());

Phantom Reference

• Object is already marked for deletion but not yet collected by GC.
• The get() method always returns **null**.
• Used for controlling finalization and releasing resources outside heap (e.g., off-heap, native).
• Requires ReferenceQueue, through which you can know that the object is about to be deleted.

PhantomReference<Object> ref = new PhantomReference<>(new Object(), referenceQueue);

Conclusion

Today we covered key aspects of JVM, memory management, and garbage collection that most often come up in Java interviews. Of course, not everything from this list will necessarily be asked, but with it, you can confidently discuss these topics and definitely won’t be confused.