On Mon, 16 Jun 2025 16:07:22 GMT, Coleen Phillimore <cole...@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
