RFR: 8304824: NMT should not use ThreadCritical [v5]

Thomas Stuefe stuefe at openjdk.org
Sun Sep 22 10:18:37 UTC 2024


On Wed, 18 Sep 2024 00:26:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge master
>>  - replace tty in pd_release_memory while holding NMT lock.
>>  - Switch to using a Hotspot Mutex.
>>  - Comments. Hide assertion behind DEBUG. Replace MemoryFileTracker locker. make reentrant.
>>  - Replace ThreadCritical with a specific NMT lock
>
> src/hotspot/share/runtime/mutexLocker.hpp line 197:
> 
>> 195:     _mutex(mutex) {
>> 196:     bool no_safepoint_check = flag == Mutex::_no_safepoint_check_flag;
>> 197:     if (_mutex != nullptr && Thread::current_or_null() != nullptr) {
> 
> I do not like this addition to the mutex locker code. First, it probably needs to be `Thread::current_or_null_safe` in case we ever lock in a signal-handling context. But second this slows down all mutex uses. Instead `NMTLocker` should extend ConditionalMutexLocker and make the current thread check the condition.

@dholmes-ora I agree with you, but it seems strange that MutexLockerImpl even handles mutex==null instead of asserting that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1770438593


More information about the serviceability-dev mailing list