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

Andrew Dinn adinn at redhat.com
Fri Nov 24 09:18:06 UTC 2017


On 23/11/17 20:43, Thomas Stüfe wrote:
> Sounds reasonable. Trying to understand: you estimate that the
> "half-eaten-medium-chunk" 
> problem is only really a bad problem for anonymous class loaders,
> because they only ever load
> one class, yes? Which is known beforehand, and we do not have to guess
> at their future
> loading behaviour, which is 0?
> 
> 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.

> How did Zhengyu arrive at the 4K limit? Why not just always use
> SpecializedChunks for
>  anon class loaders?
The limit was found by experiment -- measuring chunk usage/wastage as
various different lambdas were loaded.  Handing out up to 4
SpecializedChunks looked like it would cover most cases.

Why not just stick with SpecializedChunks? Well, some lambdas are
'bigger' than others. Also, anon loaders have been used for other cases
in the past and might be so used in the future. So, it is possible that
anon loaders might be used in situations where more than 4K (4 * 1K) is
needed.  Zhengyu's patch moves up to using a 4K chunk in two cases i) an
allocation size is too big for a 1K chunk ii) more than 4 1K chunks have
been used. Case i is necessary. Case ii seems like a hedge against what
might really be needed. Both are probably going to be uncommon for now
at least.

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