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

Metaspace chunks are uncommitted twice

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 18
    • Fix Version/s: 18
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b23

      Description

      Metaspace returns memory to the OS by uncommitting free chunks when we unload classes. Today, we uncommit free metaspace chunks twice, and the second uncommit has no effect. Therefore, one of the uncommits is unnecessary.

      In detail, when class unloading happens, we enter CLDG::purge():

      - CLDG::purge()
        - delete each CLD in the `_unloading` list
          - which deletes the associated metaspace arena(s)
            - which causes the arenas to return all of their now unused chunks to the chunk manager (`ChunkManager::return_chunk()`)
              - where the buddy allocator combines them with their neighbors if they are free
                - (A) and the resulting larger chunk gets uncommitted if it is larger than a commit granule

      - then we pop back to CLDG::purge() and call `Metaspace::purge()`
        - (B) `Metaspace::purge()` iterates through all free chunks in the chunk manager, now maximally folded, and uncommits those which are larger than a commit granule.
        
      (A) and (B) are redundant. (B) uncommits memory which had already been uncommitted in step (A). Either A or B could be dropped.

      I opt for keeping (B) and dropping (A) since:
      - it is the expected behavior. We expect `Metaspace::purge()` to do some purging.
      - (B) is less work than (A) since space is maximally defragmented at this point. All free chunks have been processed already and are therefore maximally folded by the buddy allocator.

      Note this is a minor, benign error - just eats up a bit of processing time, but probably not that much since uncommitting memory which is already uncommitted (which amounts to remapping uncommitted memory ranges) is very cheap.
           
         

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              stuefe Thomas Stuefe
              Reporter:
              stuefe Thomas Stuefe
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: