[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