On Fri, 17 Sep 2021 12:02:32 GMT, Coleen Phillimore <cole...@openjdk.org> wrote:
>> Markus Grönlund has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - remove rehashing and rely on default grow_hint for table resize >> - mtStatistics > > src/hotspot/share/runtime/mutexLocker.cpp line 323: > >> 321: >> 322: #if INCLUDE_JFR >> 323: def(JfrMsg_lock , PaddedMonitor, leaf-1, true, >> _safepoint_check_always); // -1 because the ConcurrentHashTable resize lock >> is leaf > > The ConcurrentHashTable_lock is a lock that doesn't check for safepoints, so > if you take this lock out while checking for safepoints, it should assert > when called from a JavaThread, which makes me think it's not called from a > JavaThread and should be _safepoint_check_never. > _resize_lock = > new Mutex(Mutex::nosafepoint-2, "ConcurrentHashTableResize_lock", > Mutex::_safepoint_check_never); > In my change, this is the ranking for ConcurrentHashTableResize_lock, so this > should be nosafepoint-3 if you check in after I do. Thanks, the JfrMsg_lock is acquired normally with safepoint checks when the JFR system needs to issue synchronous, blocking operations. Asynchronous operations, like message notifications, only attempt a try_lock() to avoid blocking in the case the lock is contended. The ConcurrentHashTable_lock is held during table iteration to prevent resizes from happening. Fortunately, the callback processing will only post asynchronous messages (like "Buffer full") and therefore will not reach the safepoint check. ------------- PR: https://git.openjdk.java.net/jdk/pull/4731
