[foreign] RFR 8209151: StdLibTest fails intermittently
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Fri Aug 10 10:53:00 UTC 2018
http://cr.openjdk.java.net/~mcimadamore/panama/codecache-lock-v2/
Maurizio
On 10/08/18 07:37, Sundararajan Athijegannathan wrote:
> I get 404. Is the URL correct?
>
> -Sundar
>
> On 10/08/18, 5:25 AM, Maurizio Cimadamore wrote:
>> New revision:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/codecache-lock_v2/
>>
>> I realized that there was another bug lurking: in NativeInvoker we
>> try to hold onto the UpcallHandler objects to prevent early
>> deallocation (via the UpcallStub's Cleaner). We do so by stashing all
>> the created handlers into an array list, which is held in a local
>> variable. Unfortunately, JIT optimization can cause this list to be
>> collected before the native method invocation is even started - and
>> this can trigger spurious NPE from Java code.
>>
>> I've fixed this by adding a reachability fence on the list (thx John
>> for the neat trick!).
>>
>> Maurizio
>>
>>
>> On 08/08/18 19:07, Maurizio Cimadamore wrote:
>>> The logic for retrieving and clearing native code blobs is race-y -
>>> it is sometimes possible for the binder code to retrieve a stale
>>> code blob that has just been deleted by the cleaner thread. This
>>> causes Hotspot crashes (around NativeInvoker::free_upcall_stub) and,
>>> sometimes, Java NPEs too in that area.
>>>
>>> The fix is to guard the code that accesses the CodeCache under the
>>> corresponding lock (this idiom is present elsewhere in the hotspot
>>> code, but I missed it the first time around).
>>>
>>> With the locking logic in place, I've been able to run the test 60
>>> consecutive times w/o failures (w/o the patch I'd get a failure
>>> within 10 attempts).
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/panama/codecache-lock/
>>>
>>> Maurizio
>>>
>>
More information about the panama-dev
mailing list