RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField

Tue Apr 13 12:14:59 UTC 2021

On Tue, 13 Apr 2021 11:01:10 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Indeed, this code does not need to be changed after it was generated. But I don't think it will be easy to implement simple remapping (due security restrictions). 

Why not? As far as I can see, the "Allow Unsigned Executable Memory" Hardened Runtime capability allows exactly this. Maybe it'd stop OpenJDK being notarized, but Apple doen't say so.

> It would be helpful if we could unlock only a part of the code cache for writing, leaving the other executable, but I don't know immediate way to do this.
> 
> Probably I'll convert this to draft. Meanwhile it is still worth to fix the random crash. What do you think about this patch compared to turning off fast JNI accessors?

It depends on performance. I've had a quick look at how `pthread_jit_write_protect_np` works, and it looks like some serious overhead. Can you measure, say, a few million JNI accessors to see which works best?

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

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