Monitoring CMS free list BinaryTreeDictionary statistics

[Todd Lipcon]

Hi all,

As you may recall from some discussion this summer, I work on an app that
has big problems with fragmentation, and am pretty sure there is no way to
tune CMS GC to avoid eventual fragmentation and long compaction pause.

So, my next best bet is to add monitoring within the application to
determine when fragmentation has gotten bad. If I can determine this via
some kind of metric, JNI, or undocumented API, I can have the server take
corrective action. In particular, since it is a distributed system, I can
shed load from the fragmented server gracefully, initiate a compacting GC
(or full JVM restart), and then pick the load back up. This is vastly
preferable to a 30+second GC pause!

The -XX:PrintFLSStatistics=1 option shows the fragmentation very clearly in
the GC log. I can see the average block size and max chunk size in the old
gen free list steadily drop until the point where promotion fails and a
compacting pause happens.

Is there any way to get at these two statistics short of modifying the JVM
itself (and other than gc-logging into a named pipe)? It seems like the kind
of thing that would be useful for operators even outside of my
fragmentation-happy application.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20101231/02f90155/attachment.html