RFR: JDK-8262074: Consolidate the default value of MetaspaceSize [v2]

[Thomas Stuefe]

On Tue, 23 Feb 2021 06:04:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Looks good to me. I would suggest changing the RFE title to something like "Consolidate the default value of MetaspaceSize".
>
>> Looks good to me.
> Thanks!
>> I would suggest changing the RFE title to something like "Consolidate the default value of MetaspaceSize".
> Done.

> Hi Thomas,
> 
(skip)
> > -----
> > Proposal:
> > 1) I propose to make MetaspaceSize independent from compiler. For one, if the intention was to have a lower threshold with compilers deactivated, that has never worked. E.g. on 64bit we always had a threshold of 20.75MB regardless of Xint/TieredStopAtLevel. Even if it worked, the compiler does not make that much difference in metaspace footprint.
> 
> I think it makes sense to get rid of this difference between build
> configurations.
> 
> > 2) I propose to slightly lower MetaspaceSize - on 32bit from 16M to 14M, on 64bit from 20.75M to 20M. This takes the slightly lower metaspace footprint since JEP 387 into account (less waste) and the scale I found to be higher than 1.3.
> > This is all very cautious. For the standard VM, very little changes, so this is mainly a cleanup patch. We could probably tune MetaspaceSize down to much lower levels. And/or make size it differently depending on UseSharedSpaces. However, atm I don't have time to hunt regressions due to too early GCs.
> 
> What would the motivation be for wanting to lower the size of
> MetaspaceSize? I've gotten feedback from others reporting that we
> trigger GCs too early, because of a (for them) too low MetaspaceSize.

Initial metaspace usage is probably much lower than it was when these sizes were thought up. For one, due to the CDS, which is usually on. Then, due to the reduced waste in metaspace. See measurements. This may matter for low-consumption JVMs which do class unloading - since you would never hit the threshold, you may never clean up, unless the GC runs due to other reasons.

But I admit that I do not have a good base upon which to decide which size is right. Once could say "you must be able to load as many classes as you did when this limit was thought up" which would mean we could lower the limit much more aggressivly than I did. Or we could say "dont shake the boat" and leave the limits as they are. I tried to find a middle way.

However, it also makes sense to keep the limits as they are. Then this patch is truly just a cleanup. 

I now set the 32bit limit to 16M, which is what we did have before; the 64bit threshold is set to 21M, which is 0.25M more than before, just to have a nice round number.

> 
> Thanks,
> StefanK

Thanks, Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/2675