RFR(s): 8203682: Add jcmd "VM.classloaders" command to print out class loader hierarchy, details
david.holmes at oracle.com
Mon May 28 05:23:47 UTC 2018
I had a look at this and overall seems okay - the output looks good
(though I'm not sure how useful the hex values are?).
Can't comment too much on the pretty-printing details - the proof is in
the output there. (Though have to wonder whether there is any existing
tree/graph printing logic somewhere in the OpenJDK code?)
1. Have we previously established whether a CSR request is needed for a
new Dcmd? (My initial feeling is that it is.)
2. Is ClassLoaderHierarchyVMOperation a safepoint VM-op? I would expect
it needs to be to be able to walk the CLD hierarchy, unless that is
already guaranteed to be safely walkable. Either way a comment clearly
stating that would be useful I think.
Related to #2, is it really possible to encounter a CLD in the process
of being unloaded? Wouldn't that happen at a safepoint?
On 28/05/2018 2:50 PM, Thomas Stüfe wrote:
> All tests passed on jdk-submit.
> Anyone interested in a review?
> More output examples for jcmd VM.classloaders :
> Spring framework, basic tree:
> Spring framework, including all classes:
> ... Thomas
> On Wed, May 23, 2018 at 2:46 PM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>> Dear all,
>> (not sure if this would be a serviceability or runtime rfe, so sorry
>> for crossposting)
>> may I please have feedback/reviews for this small enhancement.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203682
>> Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8203682-jcmd-print-classloader-hierarchy/webrev.00/webrev/
>> This adds a new command to jcmd, "VM.classloaders". It complements the
>> existing command "VM.classloader_stats".
>> This command, in its simplest form, prints the class loader tree. In
>> addition to that, it optionally prints out loaded classes (both
>> non-anonymous and anonymous) and various classloader specific
>> Thanks and Best Regards,
More information about the hotspot-runtime-dev