|
Yes, so I reverted back to the CLD*.
Seems to be the only thing that is unique per ClassLoader instance
and does not move.
Chris
On 2/11/15 2:11 PM, Karen Kinnear wrote:
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
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
|
