RFR: 8267879: ClassLoaderMetaspace destructor asserts on !_frozen

David Holmes dholmes at openjdk.java.net
Wed Jun 2 02:59:34 UTC 2021


On Tue, 1 Jun 2021 18:30:30 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Summary: The assert was a false negative. `Metaspace::freeze()` is obsolete and should be removed.
> 
> The original reason for the `Metaspace::freeze()` API was to ensure that the safepoint portion of -Xshare:dump, i.e., `VM_PopulateDumpSharedSpace::doit()` does not call `Metaspace::allocate()`, which might cause a GC, resulting in  a deadlock.
> 
> However, since [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149), GC would happen only with the `TRAPS` version of `Metaspace::allocate()`. Since [JDK-8252685](https://bugs.openjdk.java.net/browse/JDK-8252685), `TRAPS` must be a `JavaThread`. This means that you can no longer cause a GC inside safepoint code by calling `Metaspace::allocate()`.
> 
> `Metaspace::assert_not_frozen()` was also called by the `ClassLoaderMetaspace` allocation/deallocation functions, but none of these would cause GC. Also, anyone calling these function while a safepoint is in progress (such as the ZGC code that triggered this assert) must ensure that they won't affect any code that concurrently traverses metaspace objects inside the safepoint. Such safeguard logic is already done at a higher level, we don't need the low-level asserts inside  the `ClassLoaderMetaspace` allocation/deallocation functions.

Hi Ioi,

Thanks for the detailed explanation. This seems fine.

David

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

Marked as reviewed by dholmes (Reviewer).

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


More information about the hotspot-runtime-dev mailing list