RFR (S) 8074355: make MutexLocker smarter about non-JavaThreads

Per Liden per.liden at oracle.com
Sat Apr 27 20:49:29 UTC 2019


Hi Coleen,

Not a review, just a comment on your comment:

+  // There are a couple of existing locks that will sometimes have a 
safepoint check and
+  // sometimes not when acquired by a JavaThread, but these locks are 
set up carefully
+  // to avoid deadlocks. TODO: Fix these locks and remove 
_safepoint_check_sometimes.

Once _safepoint_check_sometimes is gone, we can simplify things even 
further and remove the {lock,wait}_without_safepoint_check() functions, 
and ditch the Mutex::SafepointCheckFlag argument in the constructors for 
MutexLocker and MonitorLocker. Everyone can just call lock()/wait(), and 
the lock itself knows what to do. That would be great!

cheers,
Per

On 04/26/2019 06:10 PM, coleen.phillimore at oracle.com wrote:
> Summary: Use safepoint_check_always/safepoint_check_never instead of 
> safepoint_check_sometimes for locks that are taken by JavaThreads and 
> non-JavaThreads
> 
> This patch moves all but 3 of the locks to not be 
> safepoint_check_sometimes.  We have plans to fix these three.  Also, 
> this patch allows for being explicit about safepoint checking or not 
> when the thread is a non-java thread, which is something that Kim 
> objected to in my first patch.
> 
> Tested with mach5 tier1-3.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8074355.03/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8074355
> 
> Thanks,
> Coleen


More information about the hotspot-dev mailing list