JVM Buzzwords Java developers should understand

This article will share with you a few JVM "buzzwords" that are important for Java developers to understand and remember before performing any JVM performance and garbage collection tuning. A few tips are also provided including some high level performance tuning best practices at the end of the article. Further recommendations regarding the Oracle HotSpot concurrent GC collectors such as CMS and G1 will be explored in future articles.

Before reading any further, I recommend that you first get familiar with the JVM verbose GC logs. Acquiring this JVM data analysis skill is essential, especially when combined with more advanced APM technologies.

JVM Buzzwords

Allocation Rate	Java objects allocated to the YoungGen space, a.k.a. “short-lived’ objects.
Promotion Rate	Java objects promoted from the YoungGen to the OldGen space.
LIVE Data	Java objects sitting in the OldGen space, a.k.a. “long-lived’ objects.
Stop-the-world Collection	Garbage collections such as Full GC and causing a temporary suspension of your application threads until completed.

First Things First: JVM GC Logs

• Provides out-of-the-box fine-grained details on the Java heap and GC activity.
• Use tools such as GCMV (GC Memory Visualizer) in order to assess your JVM pause time and memory allocation rate vs. sizing the generations by hand.

Allocation & Promotion Rates

• It is important to keep track of your application allocation and promotion rates for optimal GC performance.
• Keep the GCAdaptiveSizePolicy active, as part of the JVM ergonomics. Tune by hand only if required.

LIVE Data Calculation

• Your live application data corresponds to the OldGen occupancy after a Full GC.
• It is essential that your OldGen capacity is big enough to hold your live data comfortably and to limit the frequency of major collections and impact on your application load throughput.

Recommendation: as a starting point, tune your Java Heap size in order to achieve an OldGen footprint or occupancy after Full GC of about 50%, allowing a sufficient buffer for certain higher load scenarios (fail-over, spikes, busy business periods...).

• *Hot Spot*: watch for OldGen memory leaks!
• What is a memory leak in Java? Constant increase of the LIVE data over time...

LIVE Data Deep Dive

• JVM GC logs are great…but how you can inspect your live data?
• Java Heap Histogram snapshots and JVM Heap Dump analysis are powerful and proven approaches to better understand your application live data.
• Java profiler solutions and tools such as Oracle Java Mission Control , Java Visual VM provide advanced features for deep Java heap inspection and profiling, including tracking of your application memory allocations.

Stop-the-world Collections: GC Overhead

• YoungGen collections are less expensive but be careful with excessive allocation rate.
• It is recommended to initially size (JVM default) the YoungGen at 1/3 of the heap size.
• Remember: both YoungGen and OldGen collections are stop-the-world events!
• PermGen and Metaspace (JDK 1.8+) are collected during a Full GC, thus it is important to keep track of the Class meta data footprint and GC frequency.

Final Words & Recommendations

Best Practices

• Optimal Java Performance is not just about Java…explore all angles.
• Always rely on facts instead of guesswork.
• Focus on global tuning items first vs. premature fine-grained optimizations.
• Perform Performance & Load Testing when applicable.
• Take advantage of proven tools and troubleshooting techniques available.

To Avoid

• There are dozens of possible JVM parameters: don’t over-tune your JVM!
• You always fear what you don’t understand: good application knowledge > no fear  > better tuning recommendations.
• Never assume that your application performance is optimal.
• Don’t try to fix all problems at once, implement tuning incrementally.
• Don’t get confused and keep focus on the root cause of performance problems as opposed to the symptoms.
• Excessive trial and error approach: symptom of guesswork.

Posted in: