Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)?
Zhengyu Gu
zgu at redhat.com
Mon Nov 27 13:57:40 UTC 2017
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?
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
>>
More information about the hotspot-dev
mailing list