Class histogram output and chopping off long thin tails

[Tony Printezis]

I'll be happy if we provided a parameter to limit the histogram output. 
But, I would personally recommend that the default value for this is 
"unbounded" for the reasons I described in my previous e-mail...

Tony

On 11/14/2011 02:37 PM, Srinivas Ramakrishna wrote:
>
>
> On Mon, Nov 14, 2011 at 7:13 AM, Tony Printezis 
> <tony.printezis at oracle.com <mailto:tony.printezis at oracle.com>> wrote:
>
>     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.
>
>
> Right -- the former.
>
>
>     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.
>
>
> Sure. I can imagine there are cases where the skinny tail is 
> interesting and indeed vital. My guess (as i indicated in the email) 
> was that perhaps the
> common use case was in the top part of the histogram, and the 
> objective as you stated was compactness :-)
>
>
>     Maybe adding a new -XX parameter :-) to set N would be a good
>     compromise?
>
>
> Sure. That's what i was suggesting, plus that the default be to favor 
> compactness (because of my guesstimate on how the use-cases fell in 
> practice,
> a guesstimate that could be wrong since it was based on subjective 
> experience rather than a survey :-)
>
> thanks!
> -- ramki
>
>
>     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  <mailto: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/99072f66/attachment.html