RFR: 8067247: Crash: assert(method_holder->data() == 0 ...) failed: a) MT-unsafe modification of inline cache

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Mon Mar 28 11:14:54 UTC 2016


>
> Updated the test case, revised webrev:
> http://cr.openjdk.java.net/~jcm/8067247/webrev.hs.01
Much better! Thanks.

Best regards,
Vladimir Ivanov

>
> Best Regards,
> Jamsheed
>
> On 3/26/2016 12:12 AM, Vladimir Ivanov wrote:
>> Nice work, Jamsheed!
>>
>>>     jdk part: http://cr.openjdk.java.net/~jcm/8067247/webrev.jdk.00/
>>
>> Looks good.
>>
>>>
>>> newly added test case
>>>   hotspot part:
>>>      http://cr.openjdk.java.net/~jcm/8067247/webrev.hs.00/
>>
>> The test looks over-complicated.
>>
>> It seems what you need to do to trigger the crash is:
>>
>>   * specify -Xcomp -XX:CompileCommand=compileonly,MHInvokeTest::test
>> -XX:SoftRefLRUPolicyMSPerMB=0
>>
>>   * invoke MHInvokeTest::test once to (1) compile the method, (2) bind
>> the linker to the call site and (3) resolve the linker method;
>>
>> Method handle can point to an empty static method (no need to allocate
>> anything).
>>
>>   * clear the inline cache
>>
>>   * trigger GC (System.gc() / WB.fullGC())
>>
>> With -XX:SoftRefLRUPolicyMSPerMB=0 soft refs are treated as weak refs.
>> So, the LambdaForm should go away.
>>
>>   * invoke MH::test to trigger linker resolution again.
>>
>>
>> Or, as a different approach, write a white box test in java.lang.invoke:
>>
>>   * specify -XX:SoftRefLRUPolicyMSPerMB=0
>>
>>   * trigger MH.invokeExact() / MH.invoke() linkage
>>
>>   * check MethodTypeForm.cachedLambdaForm(LF_EX_LINKER /
>> LF_GEN_LINKER) != null
>>
>>   * trigger Full GC
>>
>>   * check LF cache again (it will be empty if the bug is present)
>>
>>>   under hs-comp/test
>>>      http://cr.openjdk.java.net/~jcm/8067247/webrev.hs_comp.00/
>>
>> Looks good.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>>
>>> Unit Test: test/compiler/jsr292/misc/gc/MHInvokeTest.java
>>> Testing: JPRT with new test case, with fix, without fix
>>>
>>> Problem Summary:  MH.invoke linksite take assistance of java code to get
>>> an adapter method. Here a new method holder class and a adapter method
>>> are created for a MT and lform instance is cached.
>>> Normally this cached lform get returned for a linksite request of same
>>> MT.  When these cached lform get collected(due to memory pressure),  a
>>> new class and method gets created for same MT(even though old method
>>> holder class and  adapter method are live).
>>> Fix Summary: Kept a strong reference to lform instance in adapter method
>>> holder class of  MT.
>>>
>>> Best Regards,
>>> Jamsheed
>>>
>>>
>>>
>>>
>


More information about the hotspot-compiler-dev mailing list