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

[Chris Plummer]

Hi Karen, Can you clarify what you mean by "address of the j.l.ClassLoader class". Is that the Klass* for the ClassLoader subclass, or the actual address of the ClassLoader instance in the heap, which can change. Chris On 2/6/15 1:21 PM, Karen Kinnear wrote: Chris, So I was curious - I was thinking you would printing the hex address of the j.l.ClassLoader class rather than the cld so that if folks were to look at a heap dump later it might be meaningful to them. Is it unlikely that they would ever want to correlate those? On Feb 6, 2015, at 3:15 PM, Chris Plummer wrote: 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. I apologize - I don't remember what I said. But I am not sure we need that level of complexity. I think I was asking that one of the dcmds that gives information could print information like 0xabc "a sun.misc.Launcher$AppClassLoader" or "a WLS.blah.GenericClassLoader" if we don't want to include that everywhere. Mostly people want to know the name of the class loader. Since they don't yet have names, they want to know the type of the classloader. So that string "a MyClassLoader" would be more meaningful than the 0xabc - except that if they have 5 of those they need the uniqueness. So personally I think I was proposing the    java.base, 0xA/"a MyClassLoader", iface). But I would defer to Staffan if he suggests something else. thanks for your patience, Karen 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