RFR: 8268406: Deallocate jmethodID native memory [v3]

Coleen Phillimore coleenp at openjdk.org
Tue Jun 17 12:59:54 UTC 2025


On Mon, 16 Jun 2025 20:33:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I can't remember.  There may have been another lock held while this one was (which is why we added MUTEX_DEFL to help with that).  I'll check.
>
> This has to be nosafepoint-1 (actually can be nosafepoint) is that it must be above the rank for the ConcurrentHashTable which is nosafepoint-2.  I don't know why it was nosafepoint-2 before this though, I can't find any lock ordering that requires this.
> 
> In general we should use the highest lock ordering within the category (no-safepoint, safepoint) possible to leave room for further locks.

Found why it needed to be nosafepoint-1.  The DEFL macro is good for the global locks but HandshakeState_lock is not global since there's one per handshake operation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2152204429


More information about the hotspot-dev mailing list