JDK-8242841 : Introduce new production switch MetaspaceReclaimPolicy
  • Type: CSR
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 16
  • Submitted: 2020-04-15
  • Updated: 2020-08-19
  • Resolved: 2020-05-15
Related Reports
CSR :  
JDK-8242622 - Introduce MetaspaceReclaimPolicy
Description
Summary
-------

Introduce new production switch "MetaspaceReclaimPolicy".

Problem
-------

The upcoming rework of the Metaspace [1] will make it more elastic: the allocator will attempt to return memory to the Operating System after class unloading, much more eagerly than it did before.

Reclaiming memory comes with costs:

1) CPU cycles are burned by uncomitting memory, mainly when populated page tables need to be torn down.

2) Uncomitting memory may increase the number of virtual memory areas (memory mappings). Depending on the OS and its virtual memory implementation, this may increase cost for memory operations and/or cause the VM process to hit an OS specific limit.

Note that both effects can be caused by any change, however minor, and usually do not require a CSR. For example, a simple malloc may cause the number of virtual memory areas to grow beyond its limit, as can creation of a new thread - each thread stack, complete with guard pages, adds two to three new mappings. The effects the new Metaspace allocator has on those effects are usually dwarfed by the "background noise" of the VM. But in corner cases they may be noticeable, and if they are we need a way to control them.

Solution
--------

We want to be able to tweak the reclamation behavior to adjust the reclamation-to-cost ratio. A number of new knobs exist for that purpose.

But instead of publishing all these knobs as new public parameters we introduce an umbrella switch which controls a whole flock of these parameters. It can be used to switch between predetermined behavior patterns. The intent is to avoid polluting the command line interface with too many new switches and to restrict parameter settings to sensible defaults.

The proposal is to name the new switch:

MetaspaceReclaimPolicy=(none|balanced|aggressive)

with each of the three possible settings describing a desired result:

- "balanced" (default) shall enable a reasonable compromise between reclaiming memory and the incurred costs. The majority of applications should see improved memory usage after class unloading while not noticing added costs. In particular, the number of virtual memory areas should only marginally increase. This setting aims to deliver backward compatible behavior while still giving the benefit of reduced memory usage.

- "aggressive" shall enable more aggressive memory reclamation at possibly increased cost. Choosing this setting means the user would be willing to increase the OS specific limit on virtual memory areas if needed. However, "aggressive" should still be a perfectly viable setting.

- "none" should disable memory reclamation altogether. 


Specification
-------------

+  product(ccstr, MetaspaceReclaimPolicy, "balanced",                                                                                                           \
+          "Select how metaspace memory is returned to the OS. Options: balanced (default), aggressive, none.")                  \

---

[1] https://bugs.openjdk.java.net/browse/JDK-8221173
Comments
Moving to Approved for JDK 16.
15-05-2020
Moving to Provisional.
20-04-2020
@Coleen: "Policy" sounds good, I went with that. I debated with myself whether to make this a diagnostic switch or a production one but decided for the latter - there are arguments for either side, but this switch feels like something which customers may need to adjust without having to specify UnlockDiagnosticVMOptions. In either case tests are of course necessary. @Goetz: I updated the switch text but left it intentionally more vague than what you proposed. Reason is that any explanation you could deliver in 5-10 words will necessarily be misleading. As it is now, the CPU and vma fragmentation overhead between "balanced" and "aggressive" is really small - so, "aggressive" is not really that aggressive at all. This may or may not change when the implementation evolves. I leave the implemetation details behind the switch settings intentionally vague, and for the same reason I would like to avoid a too descriptive settings text.
17-04-2020
Hi, Looks good to me too. I would prefer a bit more verbose description of the Switch though. Maybe: Select how metaspace memory is returned to the OS. Options: balanced, aggressive, none. 'Agressive' increases CPU/OS overhead. 'none' increases memory usage. Or vice versa: 'Aggressive' reduces memory usage. 'None" reduces CPU/OS overhead. Naming it 'Policy' sounds reasonable.
17-04-2020
Looks good to me. Normally I resist having new options but customers may need this one. I think you consolidated the effects with a reasonable summary switch name. Many other switches are called FooPolicy. Should it be Policy rather than Strategy? Opinions? We need to make sure there are adequate tests for each of the settings.
16-04-2020