Serkan ÖZAL

JVM UNDER THE HOOD

AGENDA

I. JVM Concepts

II. Memory Management

III. GC

IV. Class Loading

V. Execution Engine

VI. Multi-Threading

VII. JNI

I. JVM CONCEPTS

TERMS

• JVM

• Runs the bytecodes

• Doesn't understand Java source code

• JRE

• Execute java programs

• = JVM + Packages Classes (lang, util, math, ...) + Runtime libraries (native .dll/.so libs)

• JDK

• Compiles and builds java programs

• = JRE + Development/Debugging Tools (javac, javap, javadoc, jdb, …)

HOTSPOT

• Implementation of the JVM

• Originally developed by Sun and now owned by Oracle

• Initially available as an add-on for Java 1.2 (1999)

• Became the default Sun JVM in Java 1.3 (2000)

• = Interpreter + JIT + GC + Class loading + ...

II. MEMORY MANAGEMENT

HEAP MEMORY

NON-HEAP MEMORY

STACK

OBJECT LAYOUT

• Objects are 8 bytes aligned by default

• On JDK 8+, Can be configured by «-XX:ObjectAlignmentInBytes=?»

• Can only be power of 2 between 8-256

• All fields are type aligned

• Fields are packed in the order of their size (except references which are last)

• Sub and parent class fields are never mixed

• Use JOL (Java Object Layout) to analyze object layout

OBJECT SCHEMA

• Objects

• Mark word [4/8 bytes]

• Class pointer [4/8 bytes]

• Fields ...

• Arrays

• Mark word [4/8 bytes]

• Class pointer [4/8 bytes]

• Array length [4 bytes]

• Elements …

COMPRESSED OOPS

• Based on 8x object alignment rule

• Encode/decode by bit shifting (3 bit shift for default (8 bytes) object alignment)

• Can be configured by «-XX:+UseCompressedOops»

• Enabled by default on JDK 7+ (when heap <= 32GB)

• «-XX:+UseCompressedClassPointers» for classes on JDK 8+

OBJECT REFERENCES

• Types of references:

• Strong Reference

• Soft Reference

• Weak Reference

• Phantom Reference

• ReferenceQueue

III. GC

COLLECTION TECHNIQUES

• Copy Collection

• Mark & Sweep (+ Compact) Collection

MINOR GC

• Collects garbage from the Young (Eden + Survivors) space

• Triggered when there is not enough space in Eden for new allocation

• References from Old space to Young space are found via card marking table

MAJOR GC (≅ FULL GC)

• Collects garbage from the Old (Tenured) space

• Mostly involves compaction

• Many Major GCs are triggered by Minor GCs because of promotion failure

• Also targets PermGen (JDK 7-) and Metaspace (JDK 8+)

SERIAL GC

• Uses STW mark-copy collector for Young space

• Uses STW mark-sweep-compact collector for Old space

• Both of these collectors are single-threaded collectors

• Enabled by «-XX:+UseSerialGC»

PARALLEL GC

• Uses STW mark-copy collector for Young space

• Uses STW mark-sweep-compact collector for Old space

• Young space is collected by multi-threaded collector

• Old space is collected by single-threaded collector

• Enabled by «-XX:+UseParallelGC» (default for JDK 8-)

• «-XX:+UseParallelOldGC» for parallel Old space collector

• «-XX:ParallelGCThreads=?» (number of cores by defaults)

CMS

• Uses STW mark-copy collector for Young space

• Uses concurrent mark-sweep collector for Old space

• No compaction normally, but uses free-lists

• FullGC with compaction when “promotion failure”

• Enabled by «-XX:+UseConcMarkSweepGC»

G1

• Heap is split into a number (typically about 2048) smaller heap regions

• The regions that contain the most garbage are collected first

• Evacuation Fully Young

• Remembered Sets

• Humongous regions and objects

• Concurrent marking

• Evacuation Mixed

• Enabled by «-XX:+UseG1GC» (default at JDK 9)

• «–XX:MaxGCPauseMillis=?», default value = 200ms

SHENANDOAH

• JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector

• Drived by Red Hat

• First released on Fedore 24 on June 2016

• Not a generational garbage collector

• Concurrent, parallel and region-based garbage collector

• Supports concurrent compaction by Brooks forwarding pointers

IV. CLASS LOADING

CLASS LOADING

• Classes are loaded by classloaders

• Some core classes (java.lang, …) eagerly

• Others lazily when they are first requested

• JVM finds, parses, verifies bytecodes and generates metadata

• Class metadata is saved into Permgen (JDK 7-) / Metaspace (JDK 8+)

• Classes are searched hierarchically through classloaders

• If a class has already been loaded, it returns it

• Otherwise, it delegates the search to the parent class loader

• If the parent class loader does not find the class, tries to find and load the class itself

CLASS LOADER DELEGATION MODEL

V. EXECUTION ENGINE

INTERPRETER

• Converts bytecode into assembly code using a template table

• Template table has assembly code for each bytecode instruction

• Runtime flag «-Xint» can be used to force interpreted mode

• No compiler optimisation is performed

• Start up behaviour for most JVMs

JIT

• JVM continually monitors the code for the following critical metrics:

• Method entry counts

• Loop back branch counts

• Escape Analysis: No Escape, Arg Escape, Global Escape

• CHA: Monomorphic, Bimorphic, Megamorphic calls

• OSR (On-Stack Replacement)

• Inlining

• Intrinsic

• De-optimization

COMPILERS

• C1

• Level 1: no profiling

• Level 2: basic profiling (with invocation and back-edge counters)

• Level 3: full profiling (Inlining, CHA, ...)

• C2

• Level 4: advanced profiling (Loop unrolling, Dead Code Elimination, Escape analysis, ...)

• Tiered (C1 + C2)

• Introduced at JDK 7

• Default since JDK 8

VI. MULTI-THREADING

THREAD MANAGEMENT

• 1:1 mapping between Java threads and native OS threads

• Thread states:

• Internal VM Threads:

• VM Thread

• Periodic Task Thread

• GC Threads

• Compiler Threads

• Signal Dispatcher Thread

• Finalizer Thread

• Reference Handler Thread

• Attach Listener Thread

• ...

• _thread_new

• _thread_in_Java

• _thread_in_vm

• _thread_in_native

• _thread_blocked

SYNCHRONIZATION

• Biased Locking

• Can be disabled by «-XX:-UseBiasedLocking»

• Delay can be configured by «-XX:BiasedLockingStartupDelay»

• Can be rebiased to another thread

• Can be revoked to lightweight lock

• Lightweight Locking

• In case of contention, inflated to heavyweight lock

• Heavyweight Locking

• Uses OS mutex/condition variables

SAFEPOINT

• On safepoint

• All threads running java code (interpreted or compiled) are suspended

• Threads running native code may continue to run as long as they do not

• attempt to contact with JVM via JNI API

• return from native to java

• A thread is at safepoint

• while running JNI code

• if it is blocked, waiting or parked

• A thread is not at safepoint while running java code (interpreted or compiled)

WHEN SAFEPOINTS ARE USED?

• Garbage collection pauses

• Code deoptimization

• Class redefinition (e.g. hot swap or instrumentation)

• Biased lock revocation & Monitor deflation

• Various debug operation (e.g. deadlock check or stacktrace dump)

• Heap dumping

HOW SAFEPOINTS WORK?

• Safepoint check (polling) is implemented as memory reads a barrier

• When safepoint is required, JVM unmaps page with that address provoking page fault

• Safepoint polling exist

• between any 2 bytecodes while running in the interpreter (effectively)

• on non-counted loop back edge in C1/C2 compiled code

• on method return in C1/C2 compiled code.

VII. JNI

HOW TO USE JNI?

• Native libraries are looked up at «java.library.path»

• On Windows, it maps to «PATH»

• On Linux, it maps to «LD_LIBRARY_PATH»

• On OS X, it maps to «DYLD_LIBRARY_PATH»

• (New|Delete)GlobalRef

• (New|Delete)LocalRef

• (Get|Release)???ArrayElements

• (Get|Set)???ArrayRegion

• (Get|Release)(PrimitiveArray|String)Critical

• Exception(Occurred|Check|Clear)

• Use «-Xcheck:jni» for enabling additional checks

CRITICAL NATIVES

• Critical natives can be inlined

• Supported only in HotSpot JVM starting from JDK 7

• Must satisfy the following conditions:

• must be static and not synchronized

• argument types must be primitive or primitive arrays

• implementation must not call JNI functions

• Starts with «JavaCritical_» instead of «Java_»

• You need both critical and standard implementation

THANKS