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