[foreign] RFR 8209151: StdLibTest fails intermittently

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Aug 9 23:55:00 UTC 2018


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