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

Jamsheed C m jamsheed.c.m at oracle.com
Mon Mar 28 12:12:52 UTC 2016


Thank you Vladimir Ivanov.

Best Regards,
Jamsheed

On 3/28/2016 4:44 PM, Vladimir Ivanov wrote:
>>
>> 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