RFR: 8268406: Deallocate jmethodID native memory [v2]

[Coleen Phillimore]

On Mon, 16 Jun 2025 16:07:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/mutexLocker.cpp line 236:
>> 
>>> 234:   MUTEX_DEFN(Notification_lock               , PaddedMonitor, service);          // used for notification thread operations
>>> 235: 
>>> 236:   MUTEX_DEFN(JmethodIdCreation_lock          , PaddedMutex  , nosafepoint-1); // used for creating jmethodIDs.
>> 
>> Interesting. Why change from `nosafepoint-2` to `nosafepoint-1`?
>
> 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.

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

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