Class histogram output and chopping off long thin tails

[Stefan Karlsson]

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 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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111114/b1536712/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