[foreign] RFR 8209151: StdLibTest fails intermittently
Sundararajan Athijegannathan
sundararajan.athijegannathan at oracle.com
Fri Aug 10 06:37:06 UTC 2018
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