RFR: JDK-8276731: Metaspace chunks are uncommitted twice

[Coleen Phillimore]

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.

I think this is fine. But now get_chunk won't uncommit memory, so could there be a scenario where we need to uncommit chunks outside of class unloading?  I sort of doubt it but haven't thought about it for a long time.  What do you think?

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

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