RFR: JDK-8276731: Metaspace chunks are uncommitted twice

[Aleksey Shipilev]

On Fri, 5 Nov 2021 14:58:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Small patch for a minor, benign error, which just eats up a bit of unnecessary processing time.
> 
> 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.

This makes sense to me. Uncommitting when *returning* the chunk to ChunkManager (which I think implies the potential for reuse) is somewhat unexpected. The uncommits should quite probably be separate, as your patch currently does.

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

Marked as reviewed by shade (Reviewer).

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