Class histogram output and chopping off long thin tails

[Tony Printezis]

Ramki,

First, which version of the class histogram are you referring to? I 
assume it's the one we generate from within the JVM which goes to the GC 
log? If you were using jmap you could just pipe the output to head or 
similar.

Is your concern mainly to keep the class histogram output reasonably 
compact? FWIW, and I don't know how common this scenario is, I once 
tracked down a leak by noticing that they were 2 instances of a 
particular class instead of 1 (I was replacing once instance with a 
newly-allocated one, but the original one ended up being queued up for 
finalization and held on to a lot of space). If we only dumped the top N 
classes I would have missed this piece of information.

Maybe adding a new -XX parameter :-) to set N would be a good compromise?

Tony

On 11/11/2011 5:31 PM, Srinivas Ramakrishna wrote:
>
> I am posting this to hotspot-gc-use, but the idea is that it also post 
> to -dev (but given how
> the lists are arranged, I am posting directly to the one and not the 
> other to avoid double copies
> to those who are in the intersection of the two kists, while covering 
> those in the union of the two).
>
> I've noticed recently in my use of the the class histogram feature, 
> that in typical cases I am interested
> in the top few types of objects and not in the long thin tail. I am 
> not sure how typical my use or
> experience is, but it would appear to me (based on my limited 
> experience of late) that if we limited
> the histogram output to the top "N" (for say N = 40 or so) classes by 
> default, it would likely satisfy
> 80-90% of use cases. For the remaining 10% of use cases, one would 
> provide a complete dump,
> or a dump with more entries than available by default.
>
> I wanted to run this suggestion by everyone and see whether this would 
> have some traction
> wrt such a request.
>
> I am guessing that this may be especially useful when dealing with 
> very large applications that
> may have many different types of objects in the heap and might present 
> a very long thin (and in
> many cases uninteresting) tail. (There may be other ways of 
> restricting the output, for example
> by cutting off output below a certain population or volume threshold, 
> but simply displaying the
> top N most voluminous or populous classes would seem to be the 
> simplest....)
>
> Comments?
> -- ramki
>
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20111114/86c75dd7/attachment.html