Java Garbage Collection

I re-read "Java Performance" by Charlie Hunt and here is some general information about garbage collection - mainly for my own reference:

The Java heap size is the size of the young generation and the old generation spaces (does not include the permanent generation) (p.111)

The app memory is the heap size + the perm generation + the threads stack size (p.277)

There are three aspects to garbage collection (p.262)

• Throughput: How much time is spend in garbage collection vs. how much time is spend on executing application code
• Latency/Responsiveness: How much pause time in executing application code does GC introduce, i.e. how is the response time affected by GC
• Memory: The amount of memory used

GC Monitoring

Switch on GC monitoring using: -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:<filename> -> Analyze using GCHisto (p.121)

To shows how long the applicaton runs and how long GC takes add: -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime (p.120)


The occupancy of the young generation after a minor GC is the survivor space occupancy (p.111) 

The live data size is the amount of memory of long-lived objects in old and perm generation. It is the size of the heap after a full GC - calculate an average of multiple full GCs (p.113, 268, 274)


The parallel garbage collector is using adative heap sizing, i.e. the HotStop VM initially uses explicit young generation sizing settings (-Xmn, -XX:NewSize, ...) and the automatically adjusts young generation spaces sizes from those settings. This can be disables using the -XX:-UseAdaptiveSizePolicy flag. (p.105 & http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc-ergonomics.html)

If you wanted to know what GC ergonomics was thinking, try adding -XX:+PrintAdaptiveSizePolicy or -XX:AdaptiveSizePolicyOutputInterval=1. The later will print out information every i-th GC about what the GC ergonomics to trying to do. (https://blogs.oracle.com/jonthecollector/entry/the_unspoken_the_why_of)


Heap size starting points (p.276)

• Set -Xms & -Xmx to 3 to 4 times the live data size of the old generation
• Set -XX:PermSize and -XX:MaxPermSize to 1.2 to 1.5 times the live data size of the perm generation
• The young generation should be 1 to 1.5 times the live data size of the old generation
• The old generation should be 2 to 3 times the live data size of the old generation

If young GC is takes too long reduce young generation size - if it occures too frequently increase it (p.280)

A parallel (throughput) garbage collector overhead of near 1% is considered well tuned. With >3% overhead tuning may improve the applications performance. It should be less than 5%. The larger the heap the better the opporunity for lower gc overhead - but this will also increase the max. stop-the-world time. p. 122/314

If worst case full GC time is unacceptable switch to a concurrent GC (Concurrent Mark Sweep or G1) (p.287)