RFR: 8203817: Monitor::try_lock() should not call check_prelock_state()

Per Liden per.liden at oracle.com
Fri May 25 06:39:40 UTC 2018


In debug builds, Monitor::try_lock() calls check_prelock_state() to 
check the thread state, etc. The intention is to verify that the call is 
made from the correct context, a context where we're allowed to block 
and potentially safepoint. Unlike Monitor::lock(), Monitor::try_lock() 
will never block, hence the call to check_prelock_state() is overly 
strict and we should remove it. Removing it would match the behavior of 
all other non-blocking functions, like 
Monitor::lock_without_safepoint_check(), which doesn't call 
check_prelock_state() either (for a good reason).

The specific problem I've run into with this is related to JFR. 
Monitor::try_lock() is by JFR to allow non-blocking event generation, so 
that you can generate JFR events from "any" context without risk 
blocking/safepointing (the logic is doing something like, if try_lock() 
fails then put the event on a different queue and let the next owner of 
the lock handle it). The overly strict checks done by 
check_prelock_state() in try_lock() breaks this logic, which in turn 
means that you can't generate JFR event from "any" context as was intended.

The patch to fix this is a one-liner, just remove the call to 
check_prelock_state().

Bug: https://bugs.openjdk.java.net/browse/JDK-8203817
Webrev: http://cr.openjdk.java.net/~pliden/8203817/webrev.0

/Per


More information about the hotspot-dev mailing list