Rep. for BNY Mellon • Programming in Java since 1998 • JUG Leader @ NYJavaSIG • Creator of Java-Katas Github repository • Ardent blogger and tweeter • Saganist (with a ‘g’ not a ‘t’)
collection is: • looking up a managed memory area • identify objects in-use as live objects • mark objects no longer used as garbage • [occasionally] reclaim memory by deleting garbage 5
collection is: • looking up a managed memory area • identify objects in-use as live objects • mark objects no longer used as garbage • [occasionally] reclaim memory by deleting garbage • [occasionally] compact memory by defragmenting 5
application threads • STOP-THE-WORLD collector • Real-life analogy (Mail box): • Stop incoming mail • Single person checks current mails 11 Classification - based on collection type
application threads • STOP-THE-WORLD collector • Real-life analogy (Mail box): • Stop incoming mail • Many people check current mails 13 Classification - based on collection type
can continue • CONCURRENT collector • Real-life analogy (Mail box): • Do not stop incoming mail • One or more people check current mails 15 Classification - based on collection type
objects are live or garbage. • Typically slow • Aims for thoroughness not speed • Real-life analogy (Mail box): • check all mail • discard fliers and junk mail 18 Classification - based on object marking
not identified, object considered live. • Typically fast • Aims for speed not thoroughness • Real-life analogy (Mail box): • check mail, find fliers and discard • assume all addressed mail is not junk 20 Classification - based on object marking
fragmented • Aims for speed not contiguous space • Real-life analogy (Mail box): • remove fliers and junk mail • leave other mail as is, still cluttered Non-moving collection 28 Classification - based on space compaction
objects contiguously placed • Aims for contiguous space not speed • Real-life analogy (Road repair): • remove junk mail • stack remaining mail to make space for new Moving collection 30 Classification - based on space compaction
collection type 2. based on object marking 3. based on execution volume (run interval) 31 Classification - Spot Quiz Serial, Parallel and Concurrent Precise and Conservative
collection type 2. based on object marking 3. based on execution volume (run interval) 31 Classification - Spot Quiz Serial, Parallel and Concurrent Precise and Conservative All-at-once and Incremental
collection type 2. based on object marking 3. based on execution volume (run interval) 4. based on space compaction 31 Classification - Spot Quiz Serial, Parallel and Concurrent Precise and Conservative All-at-once and Incremental
collection type 2. based on object marking 3. based on execution volume (run interval) 4. based on space compaction 31 Classification - Spot Quiz Serial, Parallel and Concurrent Precise and Conservative All-at-once and Incremental Non-moving and Moving
collection is: • looking up a managed memory area • identify objects in-use as live objects • mark objects no longer used as garbage • [occasionally] reclaim memory by deleting garbage • [occasionally] compact memory by defragmenting 34 Garbage collection - Spot Quiz
collection is: • looking up a managed memory area • identify objects in-use as live objects • mark objects no longer used as garbage • [occasionally] reclaim memory by deleting garbage • [occasionally] compact memory by defragmenting 34 Garbage collection - Spot Quiz
O1 O2 O3 O4 O5 O6 Objects are marked in Gray to be evaluated Free Space Mark O1 O2 O3 O4 O5 O6 Live objects are marked Black, Dead objects are marked White
O1 O2 O3 O4 O5 O6 Objects are marked in Gray to be evaluated Free Space Mark O1 O2 O3 O4 O5 O6 Live objects are marked Black, Dead objects are marked White Free Space Sweep O1 O3 O5 O6 Dead objects are swept off
O1 O2 O3 O4 O5 O6 Objects are marked in Gray to be evaluated Free Space Mark O1 O2 O3 O4 O5 O6 Live objects are marked Black, Dead objects are marked White Free Space Sweep O1 O3 O5 O6 Dead objects are swept off Free Space Compact O1 O3 O5 O6 [Optional step] Compact objects to create contiguous free space
O2 O3 O4 O5 O6 Space divided into 2 equal size areas (From and To regions) “To” Region No Objects allocated here GC Begin O1 O2 O3 O4 O5 O6 Objects are marked in Gray to be evaluated “From” . “To” Region No Objects allocated here
O1 O2 O3 O4 O5 O6 Copy Live objects marked Black copied to To region O1 O3 O5 O6 “From” . Memory O1 O2 O3 O4 O5 O6 Space divided into 2 equal size areas (From and To regions) “To” Region No Objects allocated here GC Begin O1 O2 O3 O4 O5 O6 Objects are marked in Gray to be evaluated “From” . “To” Region No Objects allocated here
O1 O2 O3 O4 O5 O6 Copy Live objects marked Black copied to To region O1 O3 O5 O6 “From” . Memory O1 O2 O3 O4 O5 O6 Space divided into 2 equal size areas (From and To regions) “To” Region No Objects allocated here “From” Region Free Space Purge From region is purged. Current To region becomes new From region O1 O3 O5 O6 New “To” Region No Objects allocated here GC Begin O1 O2 O3 O4 O5 O6 Objects are marked in Gray to be evaluated “From” . “To” Region No Objects allocated here
Copying efficient for larger memory areas efficient for small memory areas works best on longer-lived objects works best on short-lived objects incremental or all-at-once collector all-at-once collector no extra free space needed to run needs 2x the memory space to run concurrent e.g. Concurrent Mark Sweep stop-the-world e.g. Mark Sweep Compact stop-the-world collector
5 • Divides memory into smaller areas • Collection patterns different per area • Based on Weak Generational Hypothesis: • Most objects don’t have a long life 43
5 • Divides memory into smaller areas • Collection patterns different per area • Based on Weak Generational Hypothesis: • Most objects don’t have a long life • Older gen. objects rarely reference younger gen. objects 43
Permanent Gen. 1 2 1 New object(s) added to Eden Age = 0 2 First GC: Live objects moved From Eden —> Survivor 1 (S1) Age = 1 See Appendix 1 for details
Permanent Gen. 1 2 3 1 New object(s) added to Eden Age = 0 2 First GC: Live objects moved From Eden —> Survivor 1 (S1) Age = 1 3 Second GC: Live objects moved From Eden, S1 —> S2 Age ++ (E —> S1 = 1, S1 —> S2 = 2) See Appendix 1 for details
Permanent Gen. 1 2 3 4 1 New object(s) added to Eden Age = 0 2 First GC: Live objects moved From Eden —> Survivor 1 (S1) Age = 1 3 Second GC: Live objects moved From Eden, S1 —> S2 Age ++ (E —> S1 = 1, S1 —> S2 = 2) 4 Third GC: Live objects moved From Eden, S2 —> S1 Age ++ (E —> S1 = 1, S2 —> S1 = 3) See Appendix 1 for details
Permanent Gen. 1 2 3 4 n } 1 New object(s) added to Eden Age = 0 2 First GC: Live objects moved From Eden —> Survivor 1 (S1) Age = 1 3 Second GC: Live objects moved From Eden, S1 —> S2 Age ++ (E —> S1 = 1, S1 —> S2 = 2) 4 Third GC: Live objects moved From Eden, S2 —> S1 Age ++ (E —> S1 = 1, S2 —> S1 = 3) n Nth GC: Live objects moved From Current Survivor —> Tenured Age ~= 15 See Appendix 1 for details ...
(sub-heaps) • newly created objects (Age = 0) —> allocated to a young area: Eden • new objects that live beyond than a GC cycle (Age = 1) —> move to a young area: Survivor (S1) • objects that “survive” a few GC cycles (Age ++ ) —> get moved between young areas: S1 -> S2 or S2 -> S1 • objects that survive longer (Age > 15) —> move to a an older area: Tenured • method definitions/statics etc —> allocated to PermGen, need not be collected 46
Eden, Survivors Old Generation Tenured Serial Collection Serial Serial Parallel Collection Parallel Scavenge Parallel Concurrent Mark-Sweep Parallel New Same as Parallel New same algorithm diff impl Concurrent Mark Sweep until compaction time (Concurrent Mode Failure) then Parallel STW GC Type Generation See Appendix 2, 2a, 2b, 2c
objects not on garbage • Contiguous memory area arrangement reduces flexibility • Different collectors for different generations 49 Issues with existing Generational GC
objects not on garbage • Contiguous memory area arrangement reduces flexibility • Different collectors for different generations • By default, unpredictable and inconsistent pause-times 49 Issues with existing Generational GC
objects not on garbage • Contiguous memory area arrangement reduces flexibility • Different collectors for different generations • By default, unpredictable and inconsistent pause-times • May need heavy tune-ups to stabilize pause times 49 Issues with existing Generational GC
objects not on garbage • Contiguous memory area arrangement reduces flexibility • Different collectors for different generations • By default, unpredictable and inconsistent pause-times • May need heavy tune-ups to stabilize pause times • Not performant for large memory heaps 49 Issues with existing Generational GC
objects not on garbage • Contiguous memory area arrangement reduces flexibility • Different collectors for different generations • By default, unpredictable and inconsistent pause-times • May need heavy tune-ups to stabilize pause times • Not performant for large memory heaps • Either highly prone to fragmentation or demand smaller heaps for predictable times. 49 Issues with existing Generational GC
a contiguous unit of memory • Both for allocation and space reclamation • Regions are formed by dividing heap into ~2048 or more equal size blocks 52 See Appendix 3 for Region Math
a contiguous unit of memory • Both for allocation and space reclamation • Regions are formed by dividing heap into ~2048 or more equal size blocks • Region sizes are from 1 MB - 32 MB (power of 2) based on the heap size 52 See Appendix 3 for Region Math
a contiguous unit of memory • Both for allocation and space reclamation • Regions are formed by dividing heap into ~2048 or more equal size blocks • Region sizes are from 1 MB - 32 MB (power of 2) based on the heap size • The memory manager assigns a region 52 See Appendix 3 for Region Math
a contiguous unit of memory • Both for allocation and space reclamation • Regions are formed by dividing heap into ~2048 or more equal size blocks • Region sizes are from 1 MB - 32 MB (power of 2) based on the heap size • The memory manager assigns a region • Regions are free, eden, survivor, tenured 52 See Appendix 3 for Region Math
a contiguous unit of memory • Both for allocation and space reclamation • Regions are formed by dividing heap into ~2048 or more equal size blocks • Region sizes are from 1 MB - 32 MB (power of 2) based on the heap size • The memory manager assigns a region • Regions are free, eden, survivor, tenured • Large objects allocated as a humongous region 52 See Appendix 3 for Region Math
complete regions • For larger objects, contiguous regions used • defined as objects ≥ 50% of region size. • not allocated as young regions • not collected in young gen. GC 53 See Appendix 3 for Region Math
for graphics Initial Mark 1. Triggers Root Scanning 2. Triggers Concurrent Marking 3. Continues the Young Collections Concurrent Marking 1. Works off a snapshot of the regions 2. Concurrent Process, not STW 3. Periodically halted by Young Collection Remark 1. Finalizes the marking 2. Finalizes Global Reference processing 3. Performs class-unloading 4. Calculated liveness information Cleanup 1. Updates internal structures 2. Reclaims completely empty regions 3. Determines a Space Reclamation need 4. Triggers a Young Collection Mixed Collection 1. Picks few Eden, Survivor and Tenured 2. Several cycles run, until heap waste low 3. Liveness of Tenured regions checked 4. Aim is to maintain consistent pause time Young Collection 1. Runs periodically to clear young regions 2. Only collection until below thresholds: • InitiatingHeapOccupancyPercent • G1ReservePercent G1GC Cycle
of JVM Heap • PermGen is implicitly bounded • PermGen is allocated at startup. • PermGen could not use O/S memory swaps. • Default PermGen size is 64M (85M for 64-bit scaled pointers). 56
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) • Max Metaspace is set by -XX:MaxMetaspaceSize (replaces -XX:MaxPermSize) 57
G1GC • 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 for large memory usage and predictable throughput • More reading material: • JEP-333 (https://openjdk.java.net/jeps/333) • ZGC Wiki (https://wiki.openjdk.java.net/display/zgc/Main) 59 (Oracle ⇢ OpenJDK) JDK 11
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 (https://openjdk.java.net/jeps/318) • Remove the Garbage Collector (https://www.infoq.com/news/2017/03/java-epsilon-gc) 60 (Redhat ⇢ OpenJDK) JDK 11
G1GC • 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 slower collection, cycles are stolen from application, but is not STW • Pause times said to be independent of heap size (be it 2GB or even 100GB) • Best for responsiveness and predictable pauses than 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) 61 (Redhat ⇢ OpenJDK) JDK 12
collection jargon Appendix 1 details about how JDK v5 - v8 generational GC works Appendix 2 details about the combinations of collectors in JDK v5 - v8 generational GCs Appendix 3 how region sizes are calculated in G1GC Appendix 4 various triggers for Initial Mark in the G1GC Young Phase Appendix 5 detailed about the Young Phase of G1GC Appendix 6 graphical representation of the collection steps in G1GC Appendix 7 printing default values for the JVM options Appendix 8 logging the garbage collection using Unified Logging
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 65 Garbage Collection - Definitions
reducing synchronization Thread Local Allocation Buffer (TLAB) • Eden itself divided into TLAB sections for • individual threads • a common area. • different GC processes for each generation • young region gc collectors typically are: • all-at-once • stop-the-world • copying pattern • old region gc typically concurrent 66 Generational GC - Details Back to Generational GC
gen. are Serial • single thread, stop-the-world • designed for small heap sizes • useful for mobile or small apps 68 Generational GC - Combinations Back to Collection Types
Scavenge • old gen. initially was a Serial • old gen. later improved to Parallel Old • default in JDK 1.5, 1.6, 1.7 and 1.8* 69 Generational GC - Combinations Back to Collection Types
uses Serial or Parallel New • old gen. uses to Concurrent Mark Sweep • eventually old gen. compaction needed • old gen. compaction is Parallel Old 70 Generational GC - Combinations Back to Collection Types
9 x 1024MB = 9216 MB 2. Approximate number of regions (2048 or more) 3. 9216 MB / 2048 regions = 4.5 MB per region 4. Power of 2 less than 4.5 = 22 = 4MB Possible regions = 9216MB / 4MB = 2304 regions 5. Power of 2 more than 4.5 = 23 = 8MB Possible regions = 9216MB / 8MB = 1152 regions 6. Choosing: 2304 ≥ 2048, so region size 4MB is chosen 7. An object is thus considered humongous if size > 50% of region Humongous object size = 2MB or greater 71 G1GC - Region Math Back to G1GC Regions
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. 73 G1GC Young Collection - Initial Mark - Triggers (1) Back to G1GC Cycle
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. 74 G1GC Young Collection - Initial Mark - Triggers (2) Back to G1GC Cycle
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 -XX:-G1EagerReclaimHumongousObjects, may need to turn on Experimental options. 75 G1GC Young Collection - Initial Mark - Triggers (3) Back to G1GC Cycle
for root objects •mark in a "dirty queue" •Update Remembered Set (RSet) •all marked references in the dirty queue updated into a RSet •Process RSet •detect references to objects in the collection set •including objects in Tenured regions •Copy Live Objects •traverse the object graph and promote/age live objects •Process references •update references to new location •process soft, weak, phantom and final references 76 G1GC Young Collection - Steps Back to G1GC Cycle
Survivor1 -> Survivor2 Back to G1GC Cycle E, SF —> ST Before After Collection Set Eden Region Survivor Region Tenured Region Humongous Objects Free space
- SATB 1. Snapshot-at-the-beginning (SATB) 2. Any changes after SATB 3. Root Scan 6. Completion 5. Children Painting 4. Root Painting Gray = To be evaluated, Black = Live, White = Dead Concurrent Marking - Snapshot-At-The-Beginning Back to G1GC Cycle New Object Added After SATB Object Dereferenced After SATB New Object Added After SATB Object Dereferenced After SATB New Object Added After SATB Object Dereferenced After SATB New Object Added After SATB Object Dereferenced After SATB New Object Added After SATB Object Dereferenced After SATB
to G1GC Cycle Collection Set Before After Eden Region Survivor Region Tenured Region Humongous Objects Free space Reference Outside Collection Set Remembered Set Add to RSet
(caution, this is a long list, best to redirect to a file) java -XX:+PrintFlagsInitial -version java -XX:+PrintFlagsInitial MyApplication Print final defaults with overridden values (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 85 G1GC - Default values - Printing or or or The -version is used as the executable above. As is shown, it can be replaced with any java class with a main(...)
JDK 8+ Option Meaning -Xlog:gc Log messages with gc tag using info level to stdout, with default decorations -Xlog:gc,safepoint Log messages with either gc or safepoint tags (exclusive), both using info level, to stdout, with default decorations -Xlog:gc+ref=debug Log messages with both gc and ref tags, using debug level, to stdout, with default decorations -Xlog:gc=debug:file=gc.txt :none Log messages with gc tag using debug level to file gc.txt with no decorations -Xlog:gc=trace:file=gc.txt: uptimemillis, pids:filecount=5,filesize=1m Log messages with gc tag using trace level to a rotating logs of 5 files of size 1MB, using the base name gc.txt, with uptimemillis and pid decorations -Xlog:gc::uptime,tid Log messages with gc tag using info level to output stdout, using uptime and tid decorations -Xlog:gc*=info, safepoint*=off Log messages with at least gc using info level, but turn off logging of messages tagged with safepoint Unified logging changes (for reference use): java -Xlog:help Understanding the content in the table: -Xlog : <tags to log>[=<log level>] [: <output> [: <decorations> ]] Reference: https://www.slideshare.net/PoonamBajaj5/lets-learn-to-talk-to-gc-logs-in-java-9
Tag Type Tag Region region Liveness liveness Marking marking Remembered Set remset Ergonomics ergo Class Histogram classhisto Safepoint safepoint Task task Heap heap JNI jni Promotion Local Allocation Buffer plab Tag Type Tag Promotion promotion Reference ref String Deduplication stringdedup Statistics stats Tenuring age Thread Local Allocation Buffer tlab Metaspace metaspace Humongous Allocation alloc Refinement refine Humongous humongous String Symbol Table stringtable Main tag is gc
cguntur
cyberagentdevelopers
yuj1osm
mhrtech
kazushi_ohata
kimujun
ar_tama
huffon
caitiem20
matthewcrist
marcelosomers
chriscoyier
kevinliebholz
moore
addyosmani
bluesmoon
ufuk
holman
thekraken
bermonpainter
![@CGuntur Mark/Sweep[/Compacting] 39 Patterns in GC Free Space GC Begin](https://files.speakerdeck.com/presentations/09de92339c23493b955f75bc4c3fce63/slide_61.jpg){kind=link}
![@CGuntur Mark/Sweep[/Compacting] 39 Patterns in GC Free Space GC Begin](https://files.speakerdeck.com/presentations/09de92339c23493b955f75bc4c3fce63/slide_62.jpg){kind=link}
![@CGuntur Mark/Sweep[/Compacting] 39 Patterns in GC Free Space GC Begin](https://files.speakerdeck.com/presentations/09de92339c23493b955f75bc4c3fce63/slide_63.jpg){kind=link}
![@CGuntur Mark/Sweep[/Compacting] 39 Patterns in GC Free Space GC Begin](https://files.speakerdeck.com/presentations/09de92339c23493b955f75bc4c3fce63/slide_64.jpg){kind=link}
![@CGuntur Comparing M/S[/C] and Copying 41 Patterns in GC Mark/Sweep[/Compact]](https://files.speakerdeck.com/presentations/09de92339c23493b955f75bc4c3fce63/slide_69.jpg){kind=link}
