Garbage Collection Mechanisms and Collectors

Why is Garbage Collecition desirable ?

GC - Programmer not responsible for freeing objects
Eliminates areas of instability , delay and maintenance

No GC - "memory management contract"
Uncoordinated libraries, frameworks , utilities

GC is efficient for allocating and freeing memory
% of CPU can be tuned for GC
Dead Objects cost nothing to collect
GC will find all dead objects ( don't worry about complexity )

Rate 1 sec per live GB - most JVM
General Usage Heap Size use - 1 -4GB

Improve Garbage Collection 

1. Architecture
2. Object Pooling
3. Off heap storage
4. Distributed heaps

Types of Garbage Collection

1. Concurrent Collector - runs with your application
2. Parallel Collector - more than 1 thread to do GC
3. Stop-the-World - GC when application is stopped
4. Incremental - performs as small discrete operations
5. Mostly - mix of GC techniques

Precise vs Conservative Collector
Conservative - unaware of object references
Precise - fully identify object references at time collector needs to run
( required for moving objects )

Commercial all Garbage Collectors are Precise

Safepoint

GC Safepoint - point or rage in thread execution where the collector can identify all the
thread's execution stack
- Bring a thread to safe point , to reach a safe point but not to stop
Global Safepoint - all threads are at safe point  - need of Stop-the-World

Precise

Identify live objects
Reclaim resources by dead objects
Periodically relocate live objects

Mechanisms

Mark/Sweep/Compact - Old Generation

Mark - start from "roots" and paint anything reachable as "live" , anything not reachable is dead
Sweep - identify "dead" objects and put in free list
Compact - contiguous dead space between objects may become too large ( similar to "swiss cheesed")
 1. move live objects to get contiguous empty space -"relocate"
 2. Correct all object references -"remap"

requires 2x only the full GC has to be run , can be stopped and restarted
Its not Monolithic .
Linear to heap size

Copying Collectors

Copy Collectors - move from space a to b , copy happens by "root"reference and copies reachable objects.Monolithic - Start can't be stopped . Copy requires 2x memory .
Linear to live-set

 Generational Collection

  - Weak generational hypothesis -"most objects die young"
 Focus collection efforts
  - use moving collector : work is linear to the live set
  - live set in the young generation is a small % of space
  - Promote objects that live long enough to older generations

Moving collector for recent objects , and use Mark sweep for old objects - Efficient and works for most objects

- Required "Remembered set" - say to track all references into the young generation
 basically multiple roots for different collectors . Move surviving objects to old generation

"Remembered set" needs memory for execution

"Card Marking"-  bit to generate oldGen is a suspect

Empty memory == CPU power

Concurrent Marking - may take a while and you may be left with no free memory
Incremental Compaction

HotSpot  - ParallelGC  ( Default Collector )

•  Monolithic STW  copy NewGen
•  Monolithic STW Mark/Sweep/Compact OldGen

HotSpot  - CocMarkSweepGC ( aka CMS )

•   Monolithic STW copy NewGen     ( ParNew )
•   Mostly Concurrent , non-Compacting  OldGen
•  Fallback to Full Collection ( Monolithic  STW )

HotSpot G1GC ( aka "Garbage First")

•  Monolithic STW copying NewGen
•  Mostly Concurrent,OldGen marker

 STW mostly incremental compacting olden
 Fallback to Full Collections

When there is a "Application Memory Wall" phenomenon its important to look at GC and Tuning