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

[coleen.phillimore at oracle.com]

On 4/27/19 4:49 PM, Per Liden wrote:
> 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!

Yes, I happen to agree with you.
Thanks!
Coleen
>
> 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