RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField

[David Holmes]

On Fri, 9 Apr 2021 18:25:10 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Hi, please review a fix for a random crash on macos/aarch64.
> 
> By default, GetXXXField JNI Interface implementation is a generated function (-XX:+UseFastJNIAccessors). Usually the function is called by JNI code running in WXExec mode and everything is fine. But sometime we attempt to call it in WXWrite context, like in the stack trace attached to the bug:
> 
> 
> v  ~BufferBlob::jni_fast_GetLongField
> V  [libjvm.dylib+0x7a6538]  Perf_Detach+0x168
> j  jdk.internal.perf.Perf.detach(Ljava/nio/ByteBuffer;)V+0 java.base at 17-internal
> j  jdk.internal.perf.Perf$CleanerAction.run()V+8 java.base at 17-internal
> j  jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup()V+4 java.base at 17-internal
> j  jdk.internal.ref.PhantomCleanable.clean()V+12 java.base at 17-internal
> j  jdk.internal.ref.CleanerImpl.run()V+57 java.base at 17-internal
> j  java.lang.Thread.run()V+11 java.base at 17-internal
> j  jdk.internal.misc.InnocuousThread.run()V+20 java.base at 17-internal
> v  ~StubRoutines::call_stub
> 
> 
> One way to fix the bug is to ensure WXExec mode before calling GetXXXField, but it depends on finding and fixing all such cases. 
> 
> This patch instead adds additional actions to GetXXXField implementation to ensure correct W^X mode regardless if it is called from WXWrite or WXExec mode.

I'm also concerned about the overall approach to W^X, but like Andrew I can accept the current proposal.

I will also sponsor this for you.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3422