[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR (S) 8014910 - deadlock between JVM/TI and compiler
From:       "serguei.spitsyn () oracle ! com" <serguei ! spitsyn () oracle ! com>
Date:       2013-10-22 19:43:04
Message-ID: 5266D548.8050305 () oracle ! com
[Download RAW message or body]

Missed this request, sorry.
It looks good.

Thanks,
Serguei

On 10/21/13 2:38 PM, Ioi Lam wrote:
> 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
>>>
>>
>

[prev in list] [next in list] [prev in thread] [next in thread]