Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Taking out the Garbage: an overview of GCs in the JVM

alblue
April 15, 2020

Taking out the Garbage: an overview of GCs in the JVM

Taking out the Garbage: an overview of garbage collectors in Java, and what new garbage collectors bring to the JVM.

alblue

April 15, 2020
Tweet

More Decks by alblue

Other Decks in Technology

Transcript

  1. ©2020 Alex Blewitt Generational Garbage Collection From Young to Old

    • Generational Hypothesis: Most objects die young • Have a young generation which is cleared periodically • Promote long-lived objects to older generations Eden Survivor Old Young
  2. ©2020 Alex Blewitt Eden • The Eden space is where

    (most) objects are allocated • Split into different thread sections called TLABs • When a thread allocates, it does so into the TLAB and bumps pointer • When out of space requests a new TLAB from Eden • If no new TLAB is available, triggers a minor collection Eden TLAB TLAB TLAB TLAB TLAB TLAB TLAB
  3. ©2020 Alex Blewitt Allocations outside TLAB • Some allocations are

    handled outside of a TLAB • If the TLAB cannot accommodate size but would waste TLAB space • If the allocation is too large for Eden and stored straight in the Old region • Small allocations outside TLAB are infrequent • Can be used to do periodic monitoring of object creation • Waste TLAB space and waste Eden space filled with dummy object • Makes parsing heaps easier
  4. ©2020 Alex Blewitt Minor GC • A Minor GC collects

    the objects in the young generation • Eden survivors are swept into the Survivor To space • Survivor From survivors are swept into the Survivor To space • Oldest objects overflow into Old space Eden Old Survivor
  5. ©2020 Alex Blewitt Minor GC • A Minor GC collects

    the objects in the young generation • Eden survivors are swept into the Survivor To space • Survivor From survivors are swept into the Survivor To space • Oldest objects overflow into Old space Eden To Old From
  6. ©2020 Alex Blewitt Object age • Each object has an

    age – the number of GCs that it has survived • Objects older than this age "Tenuring threshold" are moved into Old gen • Typically objects of a particular class have high or low ages • Objects with all ages may indicate a memory leak
  7. ©2020 Alex Blewitt Garbage Collection Algorithms • Young and Old

    gen can have different garbage collection algorithms • Young: Serial, ParallelNew, ParallelScavenge • Old: Serial, ParallelOld, ConcurrentMarkSweep* • May have a combined collector which handles everything • G1, Shenandoah, Z • Some combinations are deprecated and will be removed in future
  8. ©2020 Alex Blewitt Application Pause Time a b c d

    Application Threads Safepoint Trigger Safepoint Start
  9. ©2020 Alex Blewitt Application Pause Time a b c d

    a a a a Application Threads Safepoint Trigger Safepoint Start Safepoint End GC Threads GC Threads GC time Application Stopped Time Time To Safepoint
  10. ©2020 Alex Blewitt Parallel GC a b c d a

    a a a Application Threads GC Threads GC Threads
  11. ©2020 Alex Blewitt Serial GC a b c d a

    Application Threads GC Threads GC Threads
  12. ©2020 Alex Blewitt Concurrent GC a b c d a

    Application Threads GC Threads GC Threads a
  13. ©2020 Alex Blewitt Concurrent Parallel GC a b c d

    a Application Threads GC Threads GC Threads a a a a
  14. ©2020 Alex Blewitt Root sets • Live objects begin with

    the root sets • Thread roots (local variables, stack slots, oops used in methods) • Interned Strings • JNI references • These then point to other references • Class roots (ClassLoader(s), classes and static variables) • Instances
  15. ©2020 Alex Blewitt Regional concurrent collectors • Regional collectors split

    the memory into different regions (or pages) • Collection will process a subset of them in one go • Pause times can be adjusted by collecting different numbers of regions • Regions have flavours of 'Eden', 'To' and GCs operate similarly • ZGC uses multiply mapped virtual memory tags to identify mapped/marked objs • Updating references can co-opt application threads to fix on the fly • By moving more work into concurrent/application threads, reduce pause time
  16. ©2020 Alex Blewitt Garbage First collector • G1 tries to

    collect as much garbage first as it can • Collects Eden and Survivor regions, and some Old regions as well • Concurrently marks objects • Stops the world for relocations (evacuations) E S O H E S O E S O H O E S O H S O O O H O
  17. ©2020 Alex Blewitt Shenandoah forwarding pointers • Shenandoah concurrently evacuates

    objects from the 'From' to 'To' spaces • Needs to store old/new but ensure that users only use new copy • Stores a forwarding pointer during GC evacuation in old object mark word • Load barriers used to correctly identify new object location • Only when GC is operational and object is in collection set • Load barrier can heal stale references in application thread upon load • When all references to old object are updated it can be released • Can run on 64-bit or 32-bit systems
  18. ©2020 Alex Blewitt ZGC coloured/tagged pointers • ZGC has a

    similar from/to space but uses pointer colours to distinguish • High order bits have from/to encoded in them • Bitmask says if coloured pointer is correct for this phase • Correction taken by application thread to update incorrect pointer • Same physical memory is mapped in to multiple virtual address spaces • Read barrier can be hit by marking virtual memory as non-readable • Requires 64-bit VM memory to operate
  19. ©2020 Alex Blewitt ZGC memory mapping Mem Mem Mem Mem

    O O O O O References are repaired on load Memory mapped multiple times Memory split into pages like G1/Shenandoah regions
  20. ©2020 Alex Blewitt Comparison G1 Shenandoah Z Regional ✅ ✅

    ✅ Generational ✅ Young STW ✅ Concurrent Evacuation ✅ ✅ x86_32 ✅ ✅ x86_64 ✅ ✅ ✅ Compressed Oops ✅ ✅ Return Memory 12+ ✅ 13+ Memory 2M-? 8M-? 8M-16T Max Pause ~1s ~1ms ~1ms Supported 8-14 8u,11u,12-14 11-14 8u and 11u Backports Both Shenandoah and ZGC need UnlockExperimentalVMOptions but plan to graduate to non-experimental in JDK 15
  21. ©2020 Alex Blewitt Summary • Java GCs continue to evolve

    to provide larger memory and lower pauses • Pauses are now limited by root set (number of threads, size of stack) • Most operations are performed concurrently in regional GCs • G1 evacuation is still stop-the-world • Edge cases continue to improve and push more concurrent operations • Still some stop-the-world pauses in modern GCs but getting smaller