RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3]

[Dean Long]

On Mon, 18 Aug 2025 16:41:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 249:
>> 
>>> 247:     // If we got a SIGBUS because we tried to write into the code
>>> 248:     // cache, try enabling WXWrite mode.
>>> 249:     if (sig == SIGBUS && pc != info->si_addr && CodeCache::contains(info->si_addr) && !CodeCache::contains(pc)) {
>> 
>> This code is only needed if we forgot a call to os::thread_wx_enable_write(), right?  Could we enable it only for product builds?  It debug builds it would be nice to know where the missing os::thread_wx_enable_write() calls are.
>> Also, if this safety-net code is never triggered, it could bit-rot.  How do we test it, with a stress flag?
>
>> This code is only needed if we forgot a call to os::thread_wx_enable_write(), right?
> Yes.
> 
>> Could we enable it only for product builds? It debug builds it would be nice to know where the missing os::thread_wx_enable_write() calls are.
> 
> Now, that is a very interesting question. If we do that, then we're potentially into the "whack-a-mole" scenario David Holmes expressed disquiet about, although not in production scenarios. If we don't, then we might miss something and the consequence would be some unnecessary overhead, particularly at startup, and we might not notice.
> 
> So which do we prefer?
> 
>> Also, if this safety-net code is never triggered, it could bit-rot. How do we test it, with a stress flag?
> 
> Good point, I should do something about that.

If we are adding missing calls then we will eventually find them all, so the process should converge.  What "whack-a-mole" means to me is repeated code changes that don't converge, which seem more likely to happen if we try to over-optimize and remove calls.  I think we have a clearer idea of the "correct" placement now, so hopefully that is less likely to happen.  I'm in favor in finding missing calls if that means we avoid the signal handler, but let's get feedback from @dholmes-ora as well.
It might be good to document somewhere the rule saying exactly when when os::thread_wx_enable_write() is required (or desired) now, because it wasn't obvious to me at first.  That rule for "required" would be something like "if this could be the first write into the code cache".  For simplicity it is easier to do it for all writes, but it is tempting to try to optimize and omit it if we know that there other writes must happen first.  I think that's when we get near "whack-a-mole" territory.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2283762280