Re: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy

Fri, 06 Feb 2015 12:17:28 -0800

I was also thinking it might be a good idea to indicate what the hex value is, although still have figured out the best way of doing this. Maybe just a simple comment before the output. Keep in mind that eventually other DCMDS will also include the cld to help uniquiely identify classes across dcmd output. Also keep in mind your earlier suggestion:

java.lang.Object/0x12345600
|--java.io.Serializable/0x12345601
|--java.util.RandomAccess/0x12345602
|--java.lang.Iterable/0x12345603
| |--java.util.Collection/0x12345604
| | |--java.util.List/0x12345605
|--java.util.AbstractCollection/0x12345606
| |  implements java.util.Collection/0x12345604
| |  implements java.lang.Iterable/0x12345603
| |--java.util.AbstractList/0x12345607
| |    implements java.util.List/0x12345605
| | |--java.util.Arrays$ArrayList/0x12345608
| | |    implements java.io.Serializable/0x12345601
| | |    implements java.util.RandomAccess/0x12345602

With additions to GC.class_stats:

Index Super ClassLoader        ClassName
    1    -1 0x00000007c0034c48 java.lang.Object/0x12345600
    2     1 0x00000007c0034c48 java.util.List/0x12345605
    3    31 0x00000007c0034c48 java.util.AbstractList/0x12345607

And GC.class_histogram:

 num     #instances         #bytes  class name
----------------------------------------------
   1:           945         117736  java.lang.Object/0x12345600
   2:           442          50352  java.util.List/0x12345605
   3:           499          25288  java.util.AbstractList/0x12345607

I think in your case you assumed we would create a unique identifier for each class, but then we settled on just classname + ClassLoader identifier of some sort, and the CLD* works for that. So replace your hex class ID in the above with the hex CLD*.

Also something Karen had said is just now starting to sink in and make sense to me:

|-sun.misc.Launcher$AppClassLoader/null (0xyyy)
|-myapp/0xyyy

I think the idea here is that when printing a ClassLoader subclass, you include two CLDs. The first is for the ClassLoader that loaded the class, and the second is the CLD for the ClassLoader subclass itself. Thus the above indicates that myapp was loaded by 0xyyy, which is the sun.misc.Launcher$AppClassLoader, which was loaded by the null ClassLoader.

With regard to the '/' format, keep in mind that we also need an indicator of whether or not it's an interface, and there's also a request to include the module name when that becomes available. At one point you requested the following, which is what I was aiming for:

java.lang.Object
|--java.io.Serializable (java.base, 0x00000007c00375f8, iface)
|--java.util.RandomAccess (java.base, 0x00000007c00375f8, iface)

So maybe I can do:

java.lang.Object
|--java.io.Serializable/0x00000007c00375f8 (java.base, intf)
|--java.util.RandomAccess/0x00000007c00375f8 (java.base, intf)
...
|-sun.misc.Launcher$AppClassLoader/0x00000007c00375f8 (java.base, CLD=0x000000087654320)
|-myapp/0x000000087654320

So now the classname and its classloader id (which is the CLD*)  are grouped together to make it easy to strip out or to search for in more than one dcmd output. I think this is probably what you were striving when you proposed using '/', and other DCMDs can eventually be changed to do the same. Also, once you know the CLD of the ClassLoader, you can find out the name of the ClassLoader class by looking for CLD=<classloaderID>

I can go with "null" for the null ClassLoader if you want. I used it's ClassLoaderData* to be consistent with the other ClassLoaders. Just let me know which you prefer.

thanks,

Chris

On 2/6/15 12:52 AM, Staffan Larsen wrote:
I think this looks good! Perhaps we should give a hint as to what the hex value is? I don�t know if it is best to print this as part of a �header� printed before the rest of the output or if we should include it as part of each line �(classloaderdata*=0x080609c8)�.

/Staffan


On 6 feb 2015, at 05:49, Chris Plummer <chris.plum...@oracle.com> wrote:

[Hmm. My previous email somehow included the attachment with the dcmd output, but not the body of the message, so here it is again.]

Hey Folks,

Sorry about the delay in getting the next webrev for this out. I was sidetracked by a few other things, including being out sick of almost a week, and there were also quite a few changes to make.

I'm ready for review with an updated webrev, but thought first I'd have you look at and comment on the output. Please see the attached file. It now supports:

   printing the hierarchy for a single class
   optionally including all subclasses of the specified class (-s)
   for each class, also list all of its interfaces (-i)

The hex value in the output is the address of the ClassLoaderData for the ClassLoader of the class. I did not include the address of the Klass, but could if you think it would be useful. Changing the format of what comes after the classname is easy. Just let me know what you think is best.

I have not updated any other dcmds to be consistent with how classes are uniquely identified. A separate bug should be filed for that. Actually I thought one was, but I looked through this thread's history and could not find mention of it. I also have not implemented the reverse hierarchy dcmd. JDK-8068830 has already been filed for that, but there are no plans to work on it in the near term.

thanks,

Chris


    

    

  

























					Reply via email to