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

[David Holmes]

On Tue, 19 Aug 2025 00:31:10 GMT, Dean Long <dlong at openjdk.org> wrote:

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

I think an assert so we gradually eradicate these fallback cases is a good idea. Just hope the stacktrace shows us where we should have placed the call.

But as Dean points out, we need a way to test the fallback ... maybe a gtest?

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

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