I recently had the opportunity to test and tune the performance of several shop and portal applications built with Java and running on the Sun/Oracle JVM, among them some of the most visited in Germany. In many cases garbage collection is a key aspect of Java server performance. In the following article we take a look at the state-of-the-art advanced GC algorithms and important tuning options and compare them for diverse real-world scenarios.
Series ‘Tuning Guidelines for Java Garbage Collection’
As mentioned in a first post of this series, Oracle’s GarbageFirst (G1) collector has been a supported option in Java 7 for some time. This post examines in more detail the performance of the G1 garbage collector compared to the other collectors available in the Hotspot JVM. I used benchmark tests for this purpose instead of a real application because they can be executed and modified more easily. I found surprising strengths and weaknesses in several of Hotspot’s garbage collectors and even disclose a fully-fledged bug.
In the previous post I have shown that the GarbageFirst (G1) collector in Java 7 (and also 8ea) does a reasonable job but cannot reach the GC throughput of the “classic” collectors as soon as old generation collections come about. This article focuses on G1’s ability to control the duration of GC pauses. To this end, I refined my benchmark from the previous tests and also ran it with a huge heap size of 50 GB for which G1 was designed. I learnt that G1’s control of GC pauses is not only costly but, unfortunately, also weaker than expected.