<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Ramki,<br>
<br>
On 11/11/2011 11:31 PM, Srinivas Ramakrishna wrote:
<blockquote
cite="mid:CABzyjynbEHDOSoeGrAotd5CwZGoi=R3soHZM78sbkVEKpTM_Rg@mail.gmail.com"
type="cite"><br>
I am posting this to hotspot-gc-use, but the idea is that it also
post to -dev (but given how<br>
the lists are arranged, I am posting directly to the one and not
the other to avoid double copies<br>
to those who are in the intersection of the two kists, while
covering those in the union of the two).<br>
<br>
I've noticed recently in my use of the the class histogram
feature, that in typical cases I am interested<br>
in the top few types of objects and not in the long thin tail. I
am not sure how typical my use or<br>
experience is, but it would appear to me (based on my limited
experience of late) that if we limited<br>
the histogram output to the top "N" (for say N = 40 or so) classes
by default, it would likely satisfy<br>
80-90% of use cases. For the remaining 10% of use cases, one would
provide a complete dump,<br>
or a dump with more entries than available by default. <br>
<br>
I wanted to run this suggestion by everyone and see whether this
would have some traction<br>
wrt such a request.<br>
</blockquote>
<br>
We have this feature in JRockit's class histogram infrastructure, so
maybe one could see this as a convergence "project"?<br>
<br>
For example:<br>
$ jrcmd 14991 print_object_summary<br>
14991:<br>
<br>
--------- Detailed Heap Statistics: ---------<br>
33.3% 79k 1005 +79k [C<br>
22.3% 53k 456 +53k java/lang/Class<br>
14.2% 34k 10 +34k [B<br>
9.7% 23k 995 +23k java/lang/String<br>
5.4% 12k 304 +12k [Ljava/lang/Object;<br>
2.5% 5k 76 +5k java/lang/reflect/Method<br>
1.3% 3k 157 +3k [Ljava/lang/Class;<br>
1.3% 2k 49 +2k [Ljava/lang/String;<br>
1.1% 2k 4 +2k [Ljrockit/vm/FCECache$FCE;<br>
0.9% 2k 32 +2k java/lang/reflect/Field<br>
0.7% 1k 20 +1k [Ljava/util/HashMap$Entry;<br>
0.6% 1k 10 +1k java/lang/Thread<br>
0.6% 1k 62 +1k java/util/Hashtable$Entry<br>
0.5% 1k 5 +1k [I<br>
239kB total ---<br>
<br>
--------- End of Detailed Heap Statistics ---<br>
<br>
where the cut off is as explained with:<br>
$ jrcmd 14991 help print_object_summary<br>
...<br>
cutoff - classes that represent less than
this<br>
percentage of totallive objects (measured in<br>
size) will not be displayed.<br>
Currently the percentage should be multiplied<br>
by 1000 so 1.5%% would be 1500 (int, 500)<br>
cutoffpointsto - like cutoff but for points-to
information <br>
(int, 500)<br>
increaseonly - set if you only want to display
the classes<br>
thatincreased since the last listing (bool,<br>
false)<br>
...<br>
<br>
StefanK<br>
<br>
<blockquote
cite="mid:CABzyjynbEHDOSoeGrAotd5CwZGoi=R3soHZM78sbkVEKpTM_Rg@mail.gmail.com"
type="cite"><br>
I am guessing that this may be especially useful when dealing with
very large applications that<br>
may have many different types of objects in the heap and might
present a very long thin (and in<br>
many cases uninteresting) tail. (There may be other ways of
restricting the output, for example<br>
by cutting off output below a certain population or volume
threshold, but simply displaying the<br>
top N most voluminous or populous classes would seem to be the
simplest....)<br>
<br>
Comments?<br>
-- ramki<br>
<br>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
hotspot-gc-use mailing list
<a class="moz-txt-link-abbreviated" href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a>
<a class="moz-txt-link-freetext" href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a>
</pre>
</blockquote>
<br>
</body>
</html>