Class histogram output and chopping off long thin tails

[Srinivas Ramakrishna]

Hi Stefan -- yes, +1 for that.

With of course the option to have the entire listing if the user so chose.

I love the +increaseonly option. From my limited experience, it would
likley be
a big hit (although lacking more experience in its behaviour, i am mildly
concerned
about short-term noise/volatility confusing the user).

-- ramki

On Mon, Nov 14, 2011 at 7:51 AM, Stefan Karlsson <stefan.karlsson at oracle.com
> wrote:

> **
> Hi Ramki,
>
>
> On 11/11/2011 11: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.
>
>
> We have this feature in JRockit's class histogram infrastructure, so maybe
> one could see this as a convergence "project"?
>
> For example:
> $ jrcmd 14991 print_object_summary
> 14991:
>
> --------- Detailed Heap Statistics: ---------
> 33.3% 79k     1005    +79k [C
> 22.3% 53k      456    +53k java/lang/Class
> 14.2% 34k       10    +34k [B
>  9.7% 23k      995    +23k java/lang/String
>  5.4% 12k      304    +12k [Ljava/lang/Object;
>  2.5% 5k       76     +5k java/lang/reflect/Method
>  1.3% 3k      157     +3k [Ljava/lang/Class;
>  1.3% 2k       49     +2k [Ljava/lang/String;
>  1.1% 2k        4     +2k [Ljrockit/vm/FCECache$FCE;
>  0.9% 2k       32     +2k java/lang/reflect/Field
>  0.7% 1k       20     +1k [Ljava/util/HashMap$Entry;
>  0.6% 1k       10     +1k java/lang/Thread
>  0.6% 1k       62     +1k java/util/Hashtable$Entry
>  0.5% 1k        5     +1k [I
>      239kB total ---
>
> --------- End of Detailed Heap Statistics ---
>
> where the cut off is as explained with:
> $ jrcmd 14991 help print_object_summary
> ...
>         cutoff                  - classes that represent less than this
>                   percentage of totallive objects (measured in
>                   size) will not be displayed.
>                   Currently the percentage should be multiplied
>                   by 1000 so 1.5%% would be 1500 (int, 500)
>         cutoffpointsto          - like cutoff but for points-to
> information
>                   (int, 500)
>         increaseonly            - set if you only want to display the
> classes
>                   thatincreased since the last listing (bool,
>                   false)
> ...
>
> StefanK
>
>
> 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: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20111114/c5587b07/attachment.html