On Tue, 19 Mar 2024 09:30:52 GMT, Andrew Haley <a...@openjdk.org> wrote:
> That's very odd. The example there doesn't even involve MAP_JIT memory, so > what does it have to do with WX? @theRealAph that is the mystery we hope will be resolved once we know the nature of the underlying OS bug. Somehow switching to exec mode fixes/works-around the issue. I can imagine a missing conditional to check if the region is MAP_JIT. > Changing WX at VM state transitions is a form of temporal coupling, a classic > design smell that has caused problems for decades. The original introducers of WXEnable made the decision that the VM should be in WRITE mode unless it needs EXEC. That is the state we are presently trying to achieve with this change. If that original design choice is wrong then ... > 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? And I've asked about this every time a missing WXEnable has had to be added. We seem to be generically able to describe what kind of code needs which mode, but we seem to struggle to pin it down. Though that is what https://bugs.openjdk.org/browse/JDK-8307817 is looking at doing. > That'd (by definition) reduce the number of transitions to the minimum if we > were through. Not necessarily. It may well remove some transitions from paths that don't need it, but if you move the state change too low down the call chain you could end up transitioning much more often in code that does need it e.g. if a transitioning method is called in a loop. We need to optimise the actual call paths as well as identify specific methods. But all this discussion suggests to me that this PR is not really worth pursuing at this time - IIUC no actual failures are observed other than those pertaining to `AssertWXAtThreadSync` and that flag will be gone if we do decide to be more fine-grained about WX management. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18238#issuecomment-2007029830
