The document discusses garbage collection in the Java Virtual Machine. It outlines the runtime data areas of JVM including heap, stacks, and method area. It describes different approaches to determining if an object is live or dead including reference counting and tracing GC roots. The document then explains common garbage collection algorithms like mark-sweep and copying and how different garbage collectors in Hotspot JVM like Serial, Parallel, and CMS work. It also discusses policies for object allocation and handling promotion of objects.

1. Garbage Collection of
Java Virtual Machine
Yongqiang Li

2. Outlines
• Recall: Runtime Data Area of JVM
• Object Live or Dead?
• Algorithm of GC
• Garbage Collectors
• Policy of Object Allocation

3. Recall: Runtime Data Areas of JVM
• Program Counter Register
• Java Heap
• Java Virtual Machine Stacks
• Native Method Stacks
• Method Area

4. Object Live or Dead?
• Reference Count

5. Object Live or Dead?
• GC Roots Tracing
• GC Roots
• Reference in stack
• Class static reference
• Final reference
• JNI reference

6. Algorithm of Garbage Collection
• Mark-Sweep
• Cons
• Low performance
• More small fragments

7. • Copying
• Cons
• Some memory is wasted.
• Need memory to handle promotion
• For extreme condition, the performance is bad.

8. • Mark-Sweep-Compact

9. • Generational Collection
• For new generation, use Copying
• For old generation, use Mark-Sweep or Mark-Sweep-Compact

10. Garbage Collectors (Hotspot JVM)
• Collectors
• Serial/Serial Old
• ParNew
• Parallel Scavenge/Parallel Old
• CMS(Concurrent Mark Sweep)

11. • Serial/Serial Old
• Algorithm: for new gen, Copying; for old gen, mark-sweep-
compact
• but it will “Stop the world”!

12. • ParNew
• Multi-threaded Serial collector

13. • Parallel Scavenge/Parallel Old
• Almost like ParNew, but it focus on the control of Throughout.
• Throughout = CPU time on user code / CPU total time.
• High throughout means more efficient.
• We can use MaxGCPauseMillis and GCTimeRatio to control this
collector.

14. • CMS (Concurrent Mark Sweep)
• Steps
• CMS initial mark
• CMS concurrent mark
• CMS remark
• CMS concurrent sweep

15. Policy of Object Allocation - Handle
Promotion
• When Survivor is too small to hold all live objects, Tenured
space will try to handle promotion.
• When minor GC is going to happen, JVM will check the
average memory amount of promoted (to tenured space)
objects.
• If it is bigger than the rest amount of tenured space. JVM will
invoke Full GC instead.
• If less, JVM will check the switch of HandlePromotionFailure.
• If switch is on, only minor GC happens.
• Else, Full GC will happen.

16. 2. Object will be allocated on Eden first.
• Where is “Eden”?
• In JVM, for new generation objects, there are 1 Eden (bigger) space
and 2 Survior (called from and to; and smaller) space.
• The default ratio between Eden and Survior is 8:1.
• Use Copying algorithm

17. -verbose:gc
-Xms20M
-Xmx20M
-Xmn10M
-XX:+PrintGCDetails
-XX:SurvivorRatio=8

18. 3. Big object will be allocated on
tenured space directly.
-verbose:gc
-Xms20M
-Xmx20M
-Xmn10M
-XX:+PrintGCDetails
-XX:SurvivorRatio=8
-XX:PretenureSizeThreshold=3145728

19. 4. Long-lived objects will enter
tenured space.
• JVM will give each object an age.
• After each minor GC (on new generation), lived object’s age
will increase by 1.
• Use MaxTenuringThreshold to control the behavior.
• Dynamic threshold
• if Memory(live objects with the same age) > Total Memory of
Survivor, then Objects with the same or old age will be promoted.
And it will ignore the setting of MaxTenuringThreshold.

20. Case: MaxTenuringThreshold
-verbose:gc
-Xms20M
-Xmx20M
-Xmn10M
-XX:+PrintGCDetails
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:+PrintTenuringDistribution

21. -verbose:gc
-Xms20M
-Xmx20M
-Xmn10M
-XX:+PrintGCDetails
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=15
-XX:+PrintTenuringDistribution

22. Case: Dynamic Threshold
-verbose:gc
-Xms20M
-Xmx20M
-Xmn10M
-XX:+PrintGCDetails
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=15
-XX:+PrintTenuringDistribution