On Tue, 19 Mar 2024 04:37:41 GMT, David Holmes <dhol...@openjdk.org> wrote:
> That said we have had a lot of people looking at the overall WX state > management logic in the past week or so due to > https://bugs.openjdk.org/browse/JDK-8327860. The workaround there requires us > to be in EXEC mode That's very odd. The example there doesn't even involve MAP_JIT memory, so what does it have to do with WX? > and there are a number of folk who are questioning why "we" chose WRITE mode > as the default with a switch to EXEC, instead of EXEC as the default with a > switch to WRITE. > But whichever way that goes I think the VM state transitions are the places > to enforce that choice. Hmm. Changing WX at VM state transitions is a form of temporal coupling, a classic design smell that has caused problems for decades. It's causing problems for us now. Instead, could we tag code that needs one or the other, keep track of the current WX state in thread-local memory, and flip WX only when we know we need to? That'd (by definition) reduce the number of transitions to the minimum if we were through. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-2006498201
