RFR: JDK-8314654: Metaspace: move locking out of MetaspaceArena

[Andrew Dinn]

On Mon, 28 Aug 2023 13:18:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> We have the following relationships.
> 
> 
> 
> -->  CLD  --> ClassLoaderMetaspace  ----+---> MetaspaceArena (nonclass)
>                                         |
>                                         |                                                                
>                                         +---> MetaspaceArena (class)
> 
> 
> 
> For historical reasons, `MetaspaceArena` locks itself with a lock owned by `ClassLoaderData` on all public entry points. That is unnecessarily complex. The natural point for this locking would be in the `ClassLoaderMetaspace` class.
> 
> Moving locking up one layer reduces complexity and prepares for some upcoming Metaspace changes for Liliput.
> 
> Note: Nothing functional changes. We lock the same paths as before, only where we used to lock upon entry in MA, we now lock in the caller.
> 
> In gtests, however, I got rid entirely of locking since all those tests are single-threaded, and the implicit locking done by MA had been just unnecessary.

Looks good.

src/hotspot/share/memory/metaspace/metaspaceArena.hpp line 78:

> 76: class MetaspaceArena : public CHeapObj<mtClass> {
> 77: 
> 78:   // Reference to the chunk manager to allocate chunks from.

It might be a good idea to leave a breadcrumb comment here stating that the class expects its callers to employ a mutex to negotiate concurrent operations.

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

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15447#pullrequestreview-1600167814
PR Review Comment: https://git.openjdk.org/jdk/pull/15447#discussion_r1308662490