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