Class histogram output and chopping off long thin tails
tony.printezis at oracle.com
Mon Nov 14 14:10:17 PST 2011
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...
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:
> 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
> 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
> a guesstimate that could be wrong since it was based on subjective
> experience rather than a survey :-)
> -- ramki
> 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
>> -- ramki
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net <mailto:hotspot-gc-use at openjdk.java.net>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-use