RFR(s): https://bugs.openjdk.java.net/browse/JDK-8205531

Thomas Stüfe thomas.stuefe at gmail.com
Fri Jun 22 19:08:33 UTC 2018


Hi all,

may I have reviews for this small enhancement to the jcmd
VM.classloader diagnostic command:

https://bugs.openjdk.java.net/browse/JDK-8205531
http://cr.openjdk.java.net/~stuefe/webrevs/8205531-vm.classloader-tree-folding/webrev.00/webrev/


VM.classloaders prints a tree of class loaders. This tree can grow a
lot and become unwieldy, especially with a lot of similar loaders. One
prime example is the DelegatingClassLoader. It would be helpful were
all these loaders:

13114:
+-- <bootstrap>
      |
      +-- "platform", jdk.internal.loader.ClassLoaders$PlatformClassLoader
            |
            +-- "app", jdk.internal.loader.ClassLoaders$AppClassLoader
                  |
                  +-- test3.internals.InMemoryClassLoader
                        |
                        +-- jdk.internal.reflect.DelegatingClassLoader
                        |
                        +-- jdk.internal.reflect.DelegatingClassLoader
                        |
                        +-- jdk.internal.reflect.DelegatingClassLoader
                        |
                        +-- jdk.internal.reflect.DelegatingClassLoader
                        |
                        +-- jdk.internal.reflect.DelegatingClassLoader
                        |
                        ...... repeat 1495 times

 folded into one:

13114:
+-- <bootstrap>
      |
      +-- "platform", jdk.internal.loader.ClassLoaders$PlatformClassLoader
            |
            +-- "app", jdk.internal.loader.ClassLoaders$AppClassLoader
                  |
                  +-- test3.internals.InMemoryClassLoader
                        |
                        +-- jdk.internal.reflect.DelegatingClassLoader
(+ 1499 more)


Original idea by Bernd Eckenfels, see
http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-May/023824.html

Thank you, Thomas


More information about the serviceability-dev mailing list