RFC: JEP draft JDK-8251280: macOS/AArch64 Port

Erik Österlund erik.osterlund at oracle.com
Mon Aug 17 13:17:47 UTC 2020


Hi,

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[3] 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 
readers:
https://bugs.openjdk.java.net/browse/JDK-8221828

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.

Thanks,
/Erik

> 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 hotspot-dev mailing list