RFR 8184732: Deadlock detection improvements for 'special' locks

[coleen.phillimore at oracle.com]

On 9/29/19 7:47 PM, David Holmes wrote:
> Hi Coleen,
>
> On 28/09/2019 4:20 am, coleen.phillimore at oracle.com wrote:
>> Summary: Assert that special ranked locks cannot safepoint and 
>> allow_vm_block and remove locks from the exceptional lock
>> list in no_safepoint_verifier.
>
> That all seems okay. As always the proof of this is in the testing.

Yes.  The goal is to have bugs in our locking code (or locking checking 
code) be found quickly, before exhaustive testing, but I did do a lot of 
testing.
>
>> The Compile_lock shouldn't be used by the VM thread or it would 
>> deadlock.   Implemented most of the suggestions in the RFE.  Many 
>> have already been cleaned up.
>
> So in src/hotspot/share/oops/instanceKlass.cpp. This code:
>
> 2336   {
> 2337     MutexLocker ml(Compile_lock);
> 2338     init_implementor();
> 2339   }
>
> would cause the VMThread to acquire the Compiler_lock, which we don't 
> want. And this code is only ever executed by the VMThread as part of 
> VM_PopulateDumpSharedSpace::doit(). So the new assertion:
>
> 2336   {
> 2337     assert_locked_or_safepoint(Compile_lock);
> 2338     init_implementor();
> 2339   }
>
> seems too broad: shouldn't we just be checking we're at a safepoint?
>

I could change it to that.  I didn't know if there was a future mode 
where the CDS dumping could run concurrently, in which case, I suppose 
this code would have to conditionally lock here.

thanks,
Coleen
> Thanks,
> David
> -----
>
>> Tested with tier1 on all Oracle platforms, and tier2-6 on linux-x64, 
>> and new test.
>>
>> open webrev at 
>> http://cr.openjdk.java.net/~coleenp/2019/8184732.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8184732
>>
>> Thanks,
>> Coleen
>>