Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)?

[Thomas Stüfe]

Hi Zhengyu,

On Mon, Nov 27, 2017 at 2:57 PM, Zhengyu Gu <zgu at redhat.com> wrote:

> Hi,
>
> Sorry, I was out for Thanksgiving holiday.
>

> The prototype was done under JDK-8190729 (https://bugs.openjdk.java.net
> /browse/JDK-8190729).
>
> The patch uses up to 4 SpecializeChunks for anonymous metadata space, then
> switches to SmallChunks. It covers well with my testcases, where about
> 98.5% metadata space size is under 4K. For occasional big anonymous
> metadata spaces, it starts to allocation SmallChunks after 4K.
>
> The reason that it is on hold, is that, it appears to have missed jdk10
> train (see comments in bug). Under this circumstance, I would love to test
> more applications to see size distributions still in neighborhood of the
> assumption, or should make it another VM parameter (?).
>
> Thomas, have you seen the similar size distribution pattern, or otherwise?
>
>
Cannot say for sure. My personal tests are not a big help, they are
completely artificial.

I dug around in old logs for customer problems but did not find any cases
which clearly matched your problem. I had one case with tons of tiny
reflection class loaders, but those rarely allocated more than one spec
chunk.

In any case, I think the 4K limit sounds reasonable. Would be fine to get
this into jdk10. Should we later want to change the limit, that would be a
simple change and could easily be backported, yes?

Thanks, Thomas


>
> Thanks,
>
> -Zhengyu
>
>
>
>
> On 11/24/2017 12:23 PM, Thomas Stüfe wrote:
>
>> On Fri, Nov 24, 2017 at 10:29 AM, Andrew Dinn <adinn at redhat.com> wrote:
>>
>> One small additional comment:
>>>
>>> On 24/11/17 09:18, Andrew Dinn wrote:
>>>
>>>> On 23/11/17 20:43, Thomas Stüfe wrote:
>>>>
>>>>> ...
>>>>> Well, this sounds both simpler and more to the point than my proposal
>>>>>
>>>> (2).
>>>
>>>>
>>>> Not quite. We know that the "half-eaten-medium-chunk" problem is really
>>>> a bad problem for anonymous class loaders and Zhengyu's patch improves
>>>> that case. We don't know it is that is the only problem case. Other
>>>> loaders may only load a small number of classes -- perhaps 1, maybe 2 --
>>>> and also end up wasting a lot of space. If an app hits that case a lot
>>>> then your proposal would allow the user to configure round it.
>>>>
>>> n.b. I'm not sure we need to worry much about any such apps as this
>>> scenario is, arguably, very unlikely? I know, for example, that JBoss
>>> Modules uses many classloaders but they rarely load just one or two
>>> classes. Once you get to 3 or 4 classes I think the current behaviour
>>> will be unlikely to increase waste because larger chunks means less
>>> fragmentation. Are OSGi loaders likely to load just one or two classes
>>> for a significant number of loaders?
>>>
>>>
>>> I do not think so. I think you are right, this is less pressing once we
>> get
>> Zhengyus patch.
>> I will add the switch when there is some time, I still think it may be
>> good
>> to have.
>>
>> Kind Regards, Thomas
>>
>>
>> regards,
>>>
>>>
>>> Andrew Dinn
>>> -----------
>>> Senior Principal Software Engineer
>>> Red Hat UK Ltd
>>> Registered in England and Wales under Company Registration No. 03798903
>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>>>
>>>