RFR 8184732: Deadlock detection improvements for 'special' locks

[David Holmes]

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.

> 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?

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
>