Chris, Just saw this. I was thinking the instance in the heap since you might have multiple instances of a single subclass. Good point that it might change and so the correlation would be gone.
thanks, Karen On Feb 6, 2015, at 5:09 PM, Chris Plummer wrote: > 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 >>> >> >
