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

Zhengyu Gu zgu at redhat.com
Mon Nov 27 19:11:45 UTC 2017


Hi Thomas,

On 11/27/2017 01:47 PM, Thomas Stüfe wrote:
> Hi Zhengyu,
> 
> On Mon, Nov 27, 2017 at 2:57 PM, Zhengyu Gu <zgu at redhat.com 
> <mailto: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
>     <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.

Yes, I saw similar pattern with DelegatingClassLoader, however, I did 
not address it in this patch. I filed 8191924 
(https://bugs.openjdk.java.net/browse/JDK-8191924) to track it separately.


> 
> 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?

Yes, the changes is rather confined and should be easy to backport.
However, I am not sure it can get into jdk10, as it is target to jdk11.


Thanks,

-Zhengyu

> 
> 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
>         <mailto: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