RFR: 8266936: Add a finalization JFR event [v11]

Markus Grönlund mgronlun at openjdk.java.net
Fri Sep 17 13:55:45 UTC 2021

On Fri, 17 Sep 2021 12:02:32 GMT, Coleen Phillimore <coleenp at 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

More information about the core-libs-dev mailing list