[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR(s): jcmd VM.classloaders should fold similar loaders
From:       Thomas_Stüfe <thomas.stuefe () gmail ! com>
Date:       2018-06-27 12:30:29
Message-ID: CAA-vtUwh2OtOnMpOEM1SeRQB3Msq2ApPJe6ZNKmFDOFzrTthSQ () mail ! gmail ! com
[Download RAW message or body]

On Wed, Jun 27, 2018 at 2:21 PM, David Holmes <david.holmes@oracle.com> wro=
te:
> Hi Thomas,
>
>
> On 27/06/2018 10:13 PM, Thomas St=C3=BCfe wrote:
>>
>> Hi David,
>>
>> On Mon, Jun 25, 2018 at 7:48 AM, David Holmes <david.holmes@oracle.com>
>> wrote:
>>>
>>> Hi Thomas,
>>>
>>>
>>> On 23/06/2018 5:10 AM, Thomas St=C3=BCfe wrote:
>>>>
>>>>
>>>> Resent with the correct subject, sorry.
>>>>
>>>> ..Thomas
>>>>
>>>> On Fri, Jun 22, 2018 at 9:08 PM, Thomas St=C3=BCfe <thomas.stuefe@gmai=
l.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-tre=
e-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. On=
e
>>>>> 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 the=
y
>>> -
>>> potentially uniquely named? So if we gave all loaders a default name
>>> (like
>>> we do threads) they would all show up expanded again - right?
>>>
>>
>> This patch will fold loaders loaded by the same parent, having the
>> same class and the same or no name.
>>
>> Example:
>>
>> 25401:
>> +-- <bootstrap>
>>        |
>>        +-- "platform",
>> jdk.internal.loader.ClassLoaders$PlatformClassLoader
>>        |     |
>>        |     +-- "app", jdk.internal.loader.ClassLoaders$AppClassLoader
>>        |
>>        +-- "small-loader", test3.internals.InMemoryClassLoader (+ 1101
>> more)
>>
>> Note that I compare addresses of _Symbol_. So, loaders which have the
>> _same_ default name still fold, see example above.
>
>
> Right. So in the case of DelegatingClassloader, today this change will fo=
ld
> them all into one because they are unnamed.

Yes.

> If tomorrow we give them a
> unique name then they will no longer fold.

Yes.

> There's no substantive difference
> between the two cases that I can see so why should they present different=
ly?

There is, they are now named :)

The whole point of this exercise is to make the output of
VM.classloaders better parsable for human brains without omitting
information:

If class and name are identical, I can mentally expand
["small-loader", test3.internals.InMemoryClassLoader (+ 1101 more)] to
1102 lines of  ["small-loader", test3.internals.InMemoryClassLoader].

The moment someone starts giving his classloaders unique names, this
makes no sense anymore, since the name carries information I do not
want to hide.

> I guess I'm not sure the name is actually significant here.

Hm. So, you would ignore the name and just fold the same class? And
then what, write "various" as name for the 1101 differently named
loaders?

As I wrote, I did not want to omit information.

>
> What happens when some of these similar loaders have distinct child loade=
rs?
> How will things be grouped and displayed then?

No folding is done in that case.

Thanks, Thomas

>
> Thanks,
> David
>
>
>> Thanks, Thomas
>>
>>
>>> 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/02=
3824.html
>>>>>
>>>>> Thank you, Thomas
[prev in list] [next in list] [prev in thread] [next in thread]