[aarch64-port-dev ] RFC: JEP draft JDK-8251280: macOS/AArch64 Port
akozlov at azul.com
Mon Aug 17 16:01:07 UTC 2020
> On 2020-08-17 14:28, Andrew Haley wrote:
>> The JEP looks good to me.
Thank you for the very fast response! Would you add yourself to the reviewers field?
On 17.08.2020 16:17, Erik Österlund wrote:
>> 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:
> 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.
These new mechanisms (nmethods barriers and new invoke binding) are certainly
interesting and worth studying. I suppose the idea is to place volatile
information to the metaspace instead of the codecache, so it can be patched
more freely. But I need to read about these more carefully. Thanks for pointing!
Modifying code in runtime is a part of the problem, another is that some meta
information is stored in the codecache as well. For example, an allocation of a
new code blob requires write capability to the code cache (allocator's data is
near the blob). And blobs such as native adapters may be allocated and filled
in on-demand, in a runtime call on a java thread, one that executed generated
code before the call.
Fortunately, it appears that Apple hasn't meant to break self-modifying
programs, so they've introduced a mechanism (pthread_jit_write_protect_np)
that allows seeing pages as writable or executable depending on a state of the
current thread, not a state of the target page. This ability may make the
W^X implementation more straightforward and more boring than expected :)
More information about the aarch64-port-dev