RFR: JDK-8306696: Remove MetaspaceReclaimPolicy=aggressive and deprecate MetaspaceReclaimPolicy

[David Holmes]

On Sat, 22 Apr 2023 07:35:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The diagnostic setting MetaspaceReclaimPolicy=aggressive is very rarely used, and I would like to remove it. This is a part of a larger effort to simplify metaspace coding and cut down on testing time, in preparation for upcoming changes to Metaspace with Lilliput.
> 
> MetaspaceReclaimPolicy had recently been demoted from an official to a diagnostic switch (see CSR [JDK-8302130](https://bugs.openjdk.org/browse/JDK-8302130)). See also the CSR text for a more in-depth explanation of what this switch does, its history, and why it could be removed for good.
> 
> The switch has not that much impact on RSS reduction but has the side effect of increasing VMA fragmentation compared to the default setting since it reduces the size of metaspace commit granules from 64K to 16K. The settings used by default (MetaspaceReclaimPolicy=balanced) are proven now in the field and can be used without alternatives (since any alternative has to be tested).
> 
> Since this would remove the last valid value for MetaspaceReclaimPolicy apart from its default "balanced" value, it makes sense to deprecate MetaspaceReclaimPolicy at the same time.
> 
> This allows us to cut down on Metaspace testing quite a bit since it removes one permutation from the test set.

Changes requested by dholmes (Reviewer).

src/hotspot/share/runtime/arguments.cpp line 507:

> 505:   { "RequireSharedSpaces",          JDK_Version::jdk(18), JDK_Version::jdk(19), JDK_Version::undefined() },
> 506:   { "UseSharedSpaces",              JDK_Version::jdk(18), JDK_Version::jdk(19), JDK_Version::undefined() },
> 507:   { "MetaspaceReclaimPolicy",       JDK_Version::jdk(21), JDK_Version::undefined(), JDK_Version::undefined() },

What you have done isn't deprecation, it is obsoletion - the flag is accepted but completely ignored (which is fine by me for a diagnostic flag). The above should be changed accordingly, or else continue to parse the flag and check for a valid value.

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

PR Review: https://git.openjdk.org/jdk/pull/13597#pullrequestreview-1403341164
PR Review Comment: https://git.openjdk.org/jdk/pull/13597#discussion_r1178718308