RFR(s): jcmd VM.classloaders should fold similar loaders

[David Holmes]

Hi Thomas,

On 23/06/2018 5:10 AM, Thomas Stüfe wrote:
> Resent with the correct subject, sorry.
> 
> ..Thomas
> 
> On Fri, Jun 22, 2018 at 9:08 PM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>> 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)

I don't quite understand that. These are different instances aren't they 
- potentially uniquely named? So if we gave all loaders a default name 
(like we do threads) they would all show up expanded again - right?

typo:

!   // we we add a

Not a review as I don't know any of the logic being modified.

David

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