> On 6 feb 2015, at 21:15, Chris Plummer <chris.plum...@oracle.com> 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. > > 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)
This looks good to me. > ... > |-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. If we change the CLD* to the “Klass of the j.l.ClassLoader”, then it will become “null”. If someone wants to find the CLD* for the null ClassLoader, then the VM.classloader_stats command will get that. /Staffan > > 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> >>> <mailto: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 >
