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

[Andrew Haley]

On Tue, 19 Aug 2025 07:39:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm not sure I'm really understanding the rules here. Is it the case that the old code would switch between write and exec in a more block structured pattern - changing when needed

The old code doesn't change when needed but at every VM transition whether needed or not. But only 1% of VM transitions need to change.

> and then restoring. But the new approach only changes when needed and never restores?

More or less, yes. (Although obviously we have to reset the mode when returning from VM mode.)

> If so then I worry that the need to change mode at any given point is a function of the code path to that point, rather than being an obvious property of the code itself.

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?

> The "healing" allows this to work, 

To be clear: healing never happens in testing.

> but I'm not sure how you would ever explain the placement rules to anyone. ?? For example, I find the placement within the `Assembler` constructor extremely obscure but presumably the code that creates the `Assembler` instance then proceeds to use that instance to write into the code cache?

Yes, exactly. We create Assembler instances whenever we need to generate code, and we don't share those instances, so the constructor is sweet spot to change mode. We don't keep Assembler instances hanging around. We could argue that this is temporal coupling, a code smell, but WX mode is a temporal property, so to a large extent that can't be helped..

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

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