Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8242841

Introduce new production switch MetaspaceReclaimPolicy

    XMLWordPrintable

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P4
    • Resolution: Approved
    • Fix Version/s: 16
    • Component/s: hotspot
    • Labels:
      None
    • Subcomponent:
    • Compatibility Kind:
      behavioral
    • Compatibility Risk:
      minimal
    • Compatibility Risk Description:
      Minimal risk, since that switch does not exist in the current JDK.
    • Interface Kind:
      add/remove/modify command line option
    • Scope:
      JDK

      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

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              stuefe Thomas Stuefe
              Reporter:
              stuefe Thomas Stuefe
              Reviewed By:
              Coleen Phillimore, Goetz Lindenmaier
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: