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
