[aarch64-port-dev ] RFC: JEP draft JDK-8251280: macOS/AArch64 Port
erik.osterlund at oracle.com
Mon Aug 17 13:17:47 UTC 2020
On 2020-08-17 14:28, Andrew Haley wrote:
> On 13/08/2020 15:47, Anton Kozlov wrote:
>> Another example would be a solution to the W^X problem, parts of
>> which may be useful for OpenJDK in hardened runtime configuration
>> on mac/x86 (the one which will use MAP_JIT mmap() flag).
> The JEP looks good to me.
> Re W^X: there are very few places where we now need runtime-patchable
> methods in the code cache.
> On AArch64, we deoptimize and recompile rather than patch in most
> cases. This is because the only instructions we're allowed to patch
> concurrently are direct jumps, traps, and nops.
> This leads to very little slowdown in practice because in a tiered-
> compilation-enabled JVM 90% of recompilations are due to tier
> escalation rather than patching needed, and most fields are resolved
> in the interpreter before C1 kicks in.
> The remaining places we patch today are
> nmethod::make_not_entrant_or_zombie and compiled inline caches for
> method calls. We can perhaps get rid of the first because we now have
> nmethod entry barriers, and Erik Österlund has been working on a
> replacement for inline caches.
Right. The relevant JEP draft for these changes is here for interested
In my current implementation prototype, all the above code patching has
indeed been removed.
I still have the nmethod entry barriers, but as mentioned they do not
patch anything on AArch64.
> Finally, we would have to change the trampoline logic to go via a
> separate data table.
> I think that's it. Not that I'm suggesting you need this for Apple/
> AArch64, but we're very close.
More information about the aarch64-port-dev