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
