I was profiling a java functional test that was taking a long time and exhibiting occasional OOM's (in C heap, not java) and I found a really sub-optimal behavior in the java serial GC (and it probably applies to all java GC's.)
Here's a sample of Permgen statistics at full GC points from the test run (size in KB):
before after commit
167935 167935 167936
172031 172031 172032
As you can see, permgen space isn't getting cleaned by these full gc runs. Not a big deal, but it points to these full gc's being useless. Additionally, the commit value is a little funny. I assumed the commit value for a gc log entry would be the value after the commit size was increased. I now think it is actually the commit value prior to the full GC run.
Additionally, I think that the permgen commit size grows at a fixed, un-tunable size of 4MB (172032K - 167936K) per full GC run. This means that if you start with a default permgen size of, say 64mb, and when your application is fully up it requires 128mb of permgen, it would require 16 full gc's for permgen to reach its final commit size.
In the case of the functional test I was profiling, 58 full gc's had to run, each taking 0.5 to 2 seconds. By making the jvm argument -XX:PermSize equal to -XX:MaxPermSize I was able to reduce that to zero full GC's (without significantly increasing the much-much-faster new-generation gc's) and reduce the GC time reported by the gc instrumentation messages by 90%, from 90 seconds to 9 seconds.
I looked numerous places but I couldn't find a different tuning parameter for the commit size growth rate for the permgen heap. It's kind of ugly to fully allocate the maximum possible size of the permgen heap at program startup. Does anyone know of an alternative to increasing PermSize to equal MaxPermSize that will achive similar results without allocating so much memory at startup? Why is the permgen commit increment so small and fixed?