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

[Ioi Lam]

Hi Coleen, here's updated patch to restore the fence_and_clear_init_lock 
and related code. Only instanceKlass.{cpp, hpp} are changed compared to 
the last review:

http://cr.openjdk.java.net/~iklam/8014910/deadlock_jvmti_comp_002/

I am rerunning the tests now.

Thanks
- Ioi

On 10/21/2013 01:08 PM, Coleen Phillimore wrote:
>
> The anti-delta of the constant pool lock looks good, but this change 
> also needs the init_lock to be set to NULL to be complete, including 
> the fence function.   Setting the init_lock to null after 
> initialization allows GC to reclaim memory for the lock object.   It 
> was moved to the mirror but that is the only difference.
>
> Coleen
>
> On 10/21/2013 03: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
>>
>