Class histogram output and chopping off long thin tails

[Srinivas Ramakrishna]

On Mon, Nov 14, 2011 at 7:13 AM, Tony Printezis
<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 listhotspot-gc-use at openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111114/47cba37e/attachment.htm>
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use