dtrace discuss - Oct 2007 - Hotspot provider returning weird class names

Howdy,

I am trying to use the hotspot provider''s object-alloc probe to
display the number of objects allocated, and the number of bytes
associated with these objects. When I run the attached [1] DTrace
script to capture this information, I periodically see classes named
"[" followed by a character:

$ dtrace objects.d
  [Ljava/lang/Object;                                          204216
  java/util/HashMap$EntryIterator                              262656
  [Ljava/lang/reflect/Field;                                   300000
  java/lang/String                                             480864
  java/lang/reflect/Field                                     1620000
  [I                                                          1636752
  [C                                                         11512240
  [B                                                         15426184

Does anyone happen to know why some classes show up this way?

Thanks for any insight,
- Ryan
-- 
UNIX Administrator
http://prefetch.net

[1]

hotspot*:::object-alloc
{
     @totalobjects[copyinstr(arg1,arg2)] = count();
     @objectbytes[copyinstr(arg1,arg2)] = sum(arg3);
}

profile:::tick-60s
{
    printf("Total objects allocated:\n");
    printa(@totalobjects);

    printf("\n\nBytes allocated:\n");
    printa(@objectbytes);
}

Matty wrote:
> Howdy,
> 
> I am trying to use the hotspot provider''s object-alloc probe to
> display the number of objects allocated, and the number of bytes
> associated with these objects. When I run the attached [1] DTrace
> script to capture this information, I periodically see classes named
> "[" followed by a character:
> 
> $ dtrace objects.d
>   [Ljava/lang/Object;                                          204216
>   java/util/HashMap$EntryIterator                              262656
>   [Ljava/lang/reflect/Field;                                   300000
>   java/lang/String                                             480864
>   java/lang/reflect/Field                                     1620000
>   [I                                                          1636752
>   [C                                                         11512240
>   [B                                                         15426184
> 
> Does anyone happen to know why some classes show up this way?
> 
> Thanks for any insight,
> - Ryan
Those are arrays.  "[I" is an array of ''int'',
"[Ljava/lang/Object;" is an array
of objects, etc.  These are the standard Java signatures as described in the JVM
Spec.

-- 
Keith McGuigan

Sun Microsystems, Inc.
1 Network Drive
Burlington, MA 10803 US
Phone (781)442-7368
Fax (781)442-1699
Email Keith.McGuigan at Sun.COM

Matty wrote:
> Howdy,
> 
> I am trying to use the hotspot provider''s object-alloc probe to
> display the number of objects allocated, and the number of bytes
> associated with these objects. When I run the attached [1] DTrace
> script to capture this information, I periodically see classes named
> "[" followed by a character:
> 
> $ dtrace objects.d
>   [Ljava/lang/Object;                                          204216
>   java/util/HashMap$EntryIterator                              262656
>   [Ljava/lang/reflect/Field;                                   300000
>   java/lang/String                                             480864
>   java/lang/reflect/Field                                     1620000
>   [I                                                          1636752
>   [C                                                         11512240
>   [B                                                         15426184
> 
> Does anyone happen to know why some classes show up this way?
> 
> Thanks for any insight,
> - Ryan
A possibly more convenient way to find out how many objects
of a given type you have is to use the "jmap -histo" command.
That will tell you how many instances of each type you have
in the heap, and how much space those instances are taking
up.  You give it an argument which is is the pid of the java
process you want to examine.  E.g.,


     $ jmap -histo 698

     num   #instances    #bytes  class name
     --------------------------------------
       1:       478       85224  [C
       2:        12       73296  [I
       3:        12       34256  [B
       4:       324       13848  [Ljava.lang.Object;
       5:        32       10240  <objArrayKlassKlass>
       6:       352        8448  java.lang.String
       7:        43        4128  java.lang.Class
       8:        37        2664  java.lang.reflect.Field
       9:        56        1880  [Ljava.lang.String;
      10:        58        1392  java.util.Hashtable$Entry
      11:        16        1280  [Ljava.util.HashMap$Entry;
      12:         9        1216  <constMethodKlass>
      13:        10        1040  [Ljava.util.Hashtable$Entry;
      14:        24         912  <symbolKlass>
      15:        56         896  java.lang.StringBuilder
     ....
     Total     2111      259760

"jmap -histo" shows you what''s in the heap right now.  If you
are only interested in the live objects, use "jmap -histo:live",
which does a full collection, then reports the statistics.  E.g.,
for the same application, at the same point shows

     $ jmap -histo:live 698

     num   #instances    #bytes  class name
     --------------------------------------
       1:       190       44672  [C
       2:         9       25168  [B
       3:       313       13048  [Ljava.lang.Object;
       4:        32       10240  <objArrayKlassKlass>
       5:       186        4464  java.lang.String
       6:        43        4128  java.lang.Class
       7:        31        2232  java.lang.reflect.Field
       8:        48        1640  [Ljava.lang.String;
       9:         6        1376  [I
      10:        57        1368  java.util.Hashtable$Entry
      11:        16        1280  [Ljava.util.HashMap$Entry;
      12:         9        1216  <constMethodKlass>
      13:        24         912  <symbolKlass>
      14:         2         816  <constantPoolKlass>
      15:         9         720  <methodKlass>
     ....
     Total     1428      128096

If you want both sets of numbers, get the total occupancy first,
then just the live objects, since getting just the live objects
forces a full collection.

jmap has the advantage over dtrace that it has no overhead until
you want to iterate the heap.  A disadvantage is that it only
shows the current occupancy of the heap, rather than the total
number of instances allocated over time.  If you make your heap
large enough, those numbers are similar. :-)

jmap produces type names the way Keith described them per the spec.
In addition it shows instances of classes that the VM itself uses,
in brokets, e.g., "<symbolKlass>".  Those objects are in the
"permanent generation", rather than in the Java object heap.

			... peter

> 
> A possibly more convenient way to find out how many objects
> of a given type you have is to use the "jmap -histo" command.
> That will tell you how many instances of each type you have
> in the heap, and how much space those instances are taking
> up.  You give it an argument which is is the pid of the java
> process you want to examine.  E.g.,
One thing to consider here is how do you run jmap in a PROD systems.

The fastest way would be to take a core out of the JVM and run jmap 
against it. Running jmap against a large JVM, usually found in app 
servers, would result in service down, which nobody is looking for that.
When you run jmap -histo your target is stopped, thing which is 
important to notice ( depending very much if you can afford the pause on 
that machine - most people have 4,6 JVMs running part of a large cluster 
and it is afordable to take down one of it for debug )

DTrace would be the most elegant way to trace object allocations.

>      $ jmap -histo:live 698
thanks for pointers. This seems to be a new feature of jdk 1.6.
At least I couldn''t find this on jdk 1.5

Rgds,
Stefan