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

[Andrew Haley]

On Thu, 21 Aug 2025 17:36:28 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> We change mode when we're _all but certain_ that we need to. That seems right to me. If the mode doesn't need changing because it's already set, that's OK. Why do you think this might be a problem?
>> 
>> My concern is that if we have code that needs a specific mode, but it is not obvious at that piece of code that this is the case, then things will work fine if somewhere on the path to that code we set the right mode. But if we introduce a new path to that code that might not be the case and so we will introduce a new place where we switch modes. That can lead to redundancy. The whole thing (as it has from day one) seems ad-hoc.
>> 
>> But if the proposed scheme performs better in general, and is not obviously "worse" from the ad-hoc perspective then ...
>
>> My concern is that if we have code that needs a specific mode, but it is not obvious at that piece of code that this is the case, then things will work fine if somewhere on the path to that code we set the right mode.
> 
> The places where transition markers are placed may appear arbitrary, but that's not so.
> 
> The process for determining the right place to put them goes as follows:
> 
> Find a point where there is a write into the code cache which causes a trap. In the control-flow graph, this is a node in the dominator tree.
> Walk up the dominator tree (i.e. walk up the stack in GDB) towards the root until you find the highest node _N_ such that the majority of nodes dominated by _N_ also write into the code cache. Place a write-enable marker at the start of the function.
> Repeat this process until there are no more traps.
> 
>  "The majority" is a judgement call, but it's not difficult in most cases. For example, any function constructing an instance of `Assembler` is almost certain to dominate a write to the code cache, and likewise any function that patches code. 
> 
> While this process doesn't guarantee an optimal solution, in practice it works pretty well, and removes 99% of W^X mode switches.

> @theRealAph Thank you so much for taking care of this! The combination of "healing" and "markers" could be the most optimal way to implement W^X transitions, it's great to see it implemented. On the start-up time, do you see the combination of healing+markers outperforms just healing?

Not really, no, but a lot of people are working on reducing startup time, so I'm loath to add an y more.

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

PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3334949924