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