RFR 8184732: Deadlock detection improvements for 'special' locks
David Holmes
david.holmes at oracle.com
Sun Sep 29 23:47:38 UTC 2019
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
>
More information about the hotspot-runtime-dev
mailing list