As a broad definition, garbage collection is the process of:

• looking up a managed memory area


• identify all objects that are in use (live objects) in this area


• mark non-live objects as garbage (unused or no-reference are other common terms)


• [occasionally] reclaim memory by deleting garbage


• [occasionally] compact memory defragmenting live objects (create more contiguous space)

This section will list a few garbage collection patterns.

The generational collector divides the memory into smaller memory areas.

Management of objects in different memory areas is done differently.

Weak Generational Hypothesis :

• Most objects do not have a long life.
• It is usually rare for an older generation object to reference a young generation object.

• heap is broken into smaller areas (sub-heaps).


• newly created objects are allocated to a young area called Eden.


• there is a per-thread region for reducing synchronization - Thread Local Allocation Buffer (TLAB)


• Eden itself divided into TLAB sections for individual threads and a common area.


• different GC processes for each generation, young gc typically is all-at-once, stop-the-world, copying collector.


• objects that stay "alive" longer get moved to older generation.


• Permanent Generation is for storing class/method definitions and static content.

• Serial Collector
  
  • Freezes all application threads to collect garbage.
  • Designed for single-thread and tiny heap sized (~100 MB) apps.
  • Low memory footprint makes it good for for mobile or small apps.


• Parallel Collector
  a.k.a Throughput collector - Java 1.5 onwards, default collector Java 1.5, 1.6, 1.7 and 1.8 (_* ↓)
  
  • Young gen., only has the parallel (scavenge) collection.
  • Tenured gen. earlier had a default serial collector (later versions changed default to parallel old collector).
  • (_*) G1GC was originally planned as default for Java 1.8 but was deferred until Java 9.


• Concurrent Mark-Sweep (CMS) Collector (mostly*) - available Java 1.5 onwards until Java 1.8
  
  • By default, Young gen. uses a serial collection and Tenured gen. use a CMS collector.
  • Does not compact by default, to make GC a low-pause, low-latency, but causes heap fragmentation.
  • An eventual fill up of old memory causes a fall-back to a STW compaction that results in performance degradation.
  • Focuses on live objects and defers garbage handling, until crisis time.
  • Parallel New does the synchronization needed for CMS that Parallel Scavenge cannot.

• Mostly focused on live objects, not on garbage (an exact antithesis of the name).
• The contiguous memory area arrangement reduces flexibility of "moving the walls".
• Required different collectors on young and tenured generations to achieve performance benefits.
• By default, unpredictable and inconsistent pause-times and lesser number of STW GCs.
• Need heavy tune-ups to stabilize pause times due to non-compacting nature of recent collectors.
• Not performant for large memory heaps (large heaps are common these days).
• Either highly prone to fragmentation or demand the need for smaller heaps for predictable times.
• Not much effort put into re-use of duplicated content.

The G1GC (Garbage First Garbage Collector), was designed and developed to resolve the above.

G1GC is the new default collector since JDK 9.

This new collector is called Garbage First Garbage Collector (G1GC).

Recommended slide deck: https://www.slideshare.net/MonicaBeckwith/java-9-the-g1-gc-awakens.

Heap is compartmentalized into virtual non-contiguous memory regions.

• A region is a contiguous unit of memory allocation and space reclamation.


• Regions are formed by dividing the heap into ~ 2048 or more blocks of equal size.


• The region sizes can range from 1 MB to 32 MB (a power of 2) depending on the heap size.


• The memory manager assigns a region as free, eden, survivor, tenured or part of a humongous allocation.


• Humongous objects occupy complete (for larger objects, contiguous) regions.


• Humongous objects are defined as objects with size > 50% of region size.


• Humongous objects are not allocated in young regions.


• G1GC has a consistent pause time-target that it tries to meet (soft, real time), hence region sizes are controlled.

1. 9GB ↠ 9GB = 9 x 1024 MB = 9216 MB.


2. Approximate region size for 2048 regions ↠ 9216 MB ÷ 2048 regions = 4.5 MB per region


3. First 2^x < 4.5 ⇉ x = 4 (MB per region). → 9216 ÷ 4MB = 2304 regions.


4. First 2^x > 4.5 ⇉ x = 8 (MB per region). → 9216 ÷ 8MB = 1152 regions.


5. Since 2304 ≥ 2048 (and 1152 < 2048), 4MB per region is chosen.


6. Each region, in this example, is calculated to be 4MB size.


7. Humongous objects, in this example, are any objects of size 2MB or above.


8. A 2.5MB object occupies one region, a 13MB object will occupy four contiguous regions.


9. Possible to disable this auto-calculation by setting a JVM option that overrides calculating.


10. Set the flag -XX:G1HeapRegionSize with a numeric value (that is a power of 2).

• The top semicircle is the most common GC process.
• When space is too fragmented or tenured occupancy hits a threshold, the bottom semi-circle is triggered.
• Eventually, neither process of the above will create contiguous memory for new allocations.
  • Until Java 9: Heavy heap occupancy will eventually lead to a Serial collecting Full GC(single-threaded).
  • From Java 10: Heavy heap occupancy will eventually lead to a Parallel collecting Full GC (multi-threaded).

• Initiating Heap Occupancy Percent (IHOP) ↠ -XX:InitiatingHeapOccupancyPercent:
  
  • Default value is 45, thus an Initial Mark is triggered when old gen heap size is 45% filled.
  • This is just an initiating value. G1 determines via measurement what the optimal percentage should be.
  • Such an adaptive HOP can be turned off by un-setting the flag (notice the -): -XX:-G1UseAdaptiveIHOP.
  • Turning off the Adaptive IHOP will make the G1 collector rely on the IHOP value alone.
  • This value is usually considered a soft threshold, reaching this limit may not immediately trigger Initial Mark.

• Guaranteed Survivor Space Availability Percent ↠ -XX:G1ReservePercent:
  
  • Default value is 10, thus an Initial Mark is triggered when survivor space availability falls to 10% filled.
  • This is a flat unchanging value. G1 honors the value set during startup.
  • This value supersedes the Heap Occupancy Percentage triggers.
  • This value is usually considered a hard threshold, reaching this limit will immediately trigger Initial Mark.

• A Humongous allocation is reached:
  
  • Humongous objects are objects with a size of 50% or greater than, a region size.
  • Directly allocated to Old gen. regions to avoid the potentially costly collections and moves of young gen.
  • G1GC tries to eagerly reclaim such objects if they are found to not have references after many collections.
  • Can be disabled by a -XX:-G1EagerReclaimHumongousObjects, may need to turn on Experimental options.

• PermGen allocated as a part of JVM Heap.
• PermGen is implicitly bounded since it is allocated at startup.
• PermGen could not take advantage of O/S memory swaps.
• Default PermGen size is 64M (85M for 64-bit scaled pointers).

---

• Metaspace (or rather metaspaces) are not a panacea for OutOfMemoryErrors.
• Metaspace is explicitly bounded from the O/S memory, taking up unlimited amounts otherwise.
• Initial Metaspace Size is set by -XX:MetaspaceSize (replaces -XX:PermSize), default = 21.8M.
• Max Metaspace is set by -XX:MaxMetaspaceSize (replaces -XX:MaxPermSize), default = unlimited.
• When porting from PermGen, simply replace -XX:PermSize and -XX:MaxPermSize with the new options.

• Pause time is used to calculate the mix and is controlled by -XX:MaxGCPauseMillis (default = 200).
• Pause time intervals controlled by an ergonomic goal that is not initially set.
  • controlled by -XX:GCPauseTimeInterval (no default).
• G1 continues with the young collection until either of the below is reached:
  • reaches a configurable soft limit known as the -XX:InitiatingHeapOccupancyPercent (default = 45).
  • reaches the configurable strict limit of -XX:G1ReservePercent (default = 10).
• If either constraint is met, it triggers the start of a Concurrent GC.
• Concurrent Mark includes both STW and concurrent activities.
• Concurrent Mark determines liveness of objects on a per-region basis.
• G1 goes after regions that have the most garbage, it is called Garbage-First.
• Concurrent Mark is followed by a Remark and a Cleanup.
• Cleanup activity is used to determine if a Space Reclamation is needed.
• Checks the percentage of garbage (waste) space to be below -XX:G1HeapWastePercent (default = 5).
• Collector picks up a minimum number of regions based on -XX:G1MixedGCCountTarget (default = 8).
  • The total number of tenured regions are divided by the above number and are picked up for collection.
• After each collection, the liveness of the tenured region is re-evaluated.
• Continues Space Reclamation if the waste percentage is still greater than the -XX:G1HeapWastePercent.

G1GC has several options that can be tuned for performance.

• Finding out what flags exist and what their default values are, is important.


• Print initial defaults for the operating system (caution, this is a long list, best to redirect to a file):
      java -XX:+PrintFlagsInitial -version
    java -XX:+PrintFlagsInitial MyApplication


• Print final defaults for the jvm, with overrides on the defaults (caution, this is a long list, best to redirect to a file):
      java -XX:+PrintFlagsFinal -version
    java -XX:+PrintFlagsFinal MyApplication


• Print current flags:
      java -XX:+PrintCommandLineFlags -version
    java -XX:+PrintCommandLineFlags MyApplication

• two or more physical processors
• two or more GB of physical memory

1. Default garbage collector = G1GC.
2. Initial heap size defaults to 1/64th of physical memory.
3. Maximum heap size defaults to 1/4th of physical memory.
4. Default tiered compiler with C1 and C2 code caches.
   • C1 pre-compiles and optimizes non-profiled (non-dynamic) code.
   • C2 profiles code and defers optimizations.

• Throughput—the percentage of total time not spent in garbage collection, considered over long periods of time.


• Pause time—the length of time the application execution is stopped for garbage collection to occur.


• GC overhead—the inverse of throughput, that is, the percentage of total time spent in garbage collection.


• Collection frequency—how often collection occurs, relative to application execution.


• Footprint—a measure of size, such as heap size.


• Promptness—the time between when an object becomes garbage and when the memory becomes available

1. Execute - execute the application to determine issues visually.
2. Monitor - use appropriate alerts/tools/logs to monitor.
3. Profile - identify the areas that need special attention.
4. Analyze - determine what needs to be done to fix issues.
5. Tune - set the right parameters for sizes, ages, threads etc.
6. Hammer - test out each set of parameters thoroughly.
7. Yippee - beer time. 🍻

• Usually caused by heavy heap occupancy.


• Logs contain the phrase Pause Full (Allocation Failure).


• This is typically preceded by a to-space exhausted message.


• Steps to mitigate:
  • Try to reduce the humongous objects.
  • Increase the java heap region size (by -XX:G1HeapRegionSize).
  • Increase number of concurrent threads (by -XX:ConcGCThreads).
  • Force earlier marking by either:
    • Lower the -XX:G1ReservePercent
    • Disable the -XX:G1UseAdaptiveIHOP and manually set -XX:InitiatingHeapOccupancyPercent.


• Full GCs can also be caused by System.gc() calls in some library.
  Effects of such can be mitigated by:
  
  • Full GC frequency can be mitigated by -XX:ExplicitGCInvokesConcurrent.
  • Last resort, completely ignore gc() calls with -XX:DisableExplicitGC.

• Young collection time is proportional to the size of the young generation.


• Reducing the -XX:G1NewSizePercent reduces the young generation size.


• Sudden spikes in the application may cause influx of live objects.


• Limiting the maximum size of the young generation can help.


• Maximum young generation size can be controlled by -XX:G1MaxNewSizePercent.

• Determine which generation is taking the time (Set gc+ergo+cset=trace in logging).


• The logs will then show predicted young region and predicted old region times.


• Spread reclamations to more mixed collections via -XX:G1MixedGCCountTarget.


• Alter (typically: reduce) threshold of collecting regions with high live occupancy:
  -XX:G1MixedGCLiveThresholdPercent.


• Alter (typically: reduce) space reclamation in high occupancy regions via -XX:G1HeapWastePercent.

This section will list a few new garbage collectors with their offered features.

• Region-based, non-generational collector, based on the G1GC.


• Adds an indirection, called Brooks Pointer (_* ↓) to each object, GC threads can compact heap while app is running.


• Young collection equivalent is run in a concurrent-partial mode.


• Uses a concurrent mark and a concurrent compact for longer lived objects.


• Evacuation and reference updates to run concurrently with application threads.


• In case of slower collection cycles, more cycles are stolen from application, but application is not halted.


• Pause times to be independent of heap size (be it 2GB or even 100GB).


• Already being improved (v2.0) to focus GC on regions where the writes happen.


• Best suited where responsiveness and predictable pauses are valued over more cpu cycles and space.


• More reading material:
  
  • JEP-189 (http://openjdk.java.net/jeps/189)
  • Shenandoah Wiki (https://wiki.openjdk.java.net/display/shenandoah/Main)
  • (_*) Shenandoah GC: Brooks pointers (https://rkennke.wordpress.com/2013/10/23/shenandoah-gc-brooks-pointers/)

• Region-based, non-generational collector, based on G1GC.


• Uses colored pointers with load barriers (_* ↓) to allow for concurrent ops.


• Load barriers act as the intermediate in determining if the object was relocated.


• Designed for very large memory heaps.


• Low GC pause times, not exceeding 10ms.


• No more than 15% application throughput reduction compared to using G1.


• Aims at simplifying tuning of GCs as well!


• Best suited for large memory usage and predictable throughput while consuming less space.


• More reading material:
  
  • OpenJDK Project (http://openjdk.java.net/projects/zgc/)
  • ZGC Wiki (https://wiki.openjdk.java.net/display/zgc/Main)
  • Per Liden (Lead) Interview (https://jaxenter.com/zgc-interview-per-liden-139985.html)
    
  • (_*) Memory Barriers/Fences (https://mechanical-sympathy.blogspot.com/2011/07/memory-barriersfences.html)

• Handles memory allocation but does not actually reclaim memory.


• Completely passive GC with just bounded memory allocation and lowest latency guarantees.


• Linear allocation in a single chunk of memory.


• Uses trivial lock-free Thread Local Allocation Buffers (TLABs) that do not need managing.


• Popular commercial implementations have a similar NoGC option already.


• Best suited for:
  
  • performance testing the app (without GC latency).
  • extremely short lived jobs.
  • memory pressure testing.


• More reading material:
  
  • JEP-318 (http://openjdk.java.net/jeps/318)
  • Remove the Garbage Collector (https://www.infoq.com/news/2017/03/java-epsilon-gc)