RFR (S) 8014910 - deadlock between JVM/TI and compiler

[serguei.spitsyn at oracle.com]

Ioi,

It looks good.
I've checked that it is a clean anti-delta for all files except the 
instanceKlass.?pp.

Thanks,
Serguei

On 10/21/13 12:37 PM, Ioi Lam wrote:
> Please review this fix:
>
> http://cr.openjdk.java.net/~iklam/8014910/deadlock_jvmti_comp_001
>
> Bug: deadlock between JVM/TI ClassPrepare event handler and 
> CompilerThread
>
>     https://bugs.openjdk.java.net/browse/JDK-8014910
>
> Summary of fix:
>
>     The deadlock was caused by this changeset:
>        https://bugs.openjdk.java.net/browse/JDK-8008962
> http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c115fac239eb
>
>     Because we use InstanceKlass::init_lock() for (1) class 
> initialization,
>     and (2) atomic modification of the class's constant pool, we could
>     deadlock when
>
>     thread A - holds class init lock and tries to grab compiler lock
>     thread B - holds compiler lock and tries to lock constant pool
>
>     The fix is to revert JDK-8008962 and use separate locks for (1) 
> and (2).
>
>
> Notes:
> [1] Although the JDK-8008962 changeset modified instanceKlass.cpp
>     and instanceKlass.hpp, the affected code (such as the original
>     function InstanceKlass::fence_and_clear_init_lock) has been rendered
>     unnecessary by other changes (8003421: NPG: Move oops out of
>     InstanceKlass into mirror), so these two files do not need to be
>     changed in this fix.
>
>
> [2] I have filed a new bug to address the memory size issue in
>     JDK-8008962:
>        https://bugs.openjdk.java.net/browse/JDK-8026977
>        Remove ConstantPool::lock
>
> Tests:
>
>     JPRT
>     UTE (vm.runtime.testlist, vm.quick.testlist, 
> vm.parallel_class_loading.testlist)
>     JCK
>     Test case in bug report.
>
> Thanks
> - Ioi
>