[aarch64-port-dev ] RFC: JEP draft JDK-8251280: macOS/AArch64 Port

[Anton Kozlov]

Hi all,

> 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:
> 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.

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[1])
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 :)

Thanks,
Anton

[1] https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon?language=objc