JDK-8328306 : Allow VM to run with WX memory execute by default
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: New
  • Resolution: Unresolved
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2024-03-16
  • Updated: 2024-03-19
Related Reports
Relates :  
Relates :  
The current approach we take with WX memory protection is to run with enabled Write by default and turning Execute as needed.
I think we should also try flipping this around and try running with Execute by default and turning Write as needed.
This would give us a better coverage and flush more codepaths to have greater confidence in our "whack the mole" approach.
That may be, but we didn't take that approach and so switching requires explicitly finding all the places where WRITE is needed. Apple's suggestions on how to write JIT'd code seem somewhat simplistic to me - and the fact they don't even mention pthread_jit_write_protect_np is interesting. And I don't think the callback approach would work with our JITs/code very well (not that I am saying you are suggesting that) - a lot of it (e.g. nmethod updates) is in shared code or in CPU rather than OS specific code.

Notice that Apple provides pthread_jit_write_with_callback_np(), but not pthread_jit_execute_with_callback_np(), which suggests that we are in fact doing things backwards. https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon

Also you need to discuss with the original porting team why they chose the current approach - ref JDK-8253795.

I'm not sure switching buys us anything. We have played whack-a-mole the last few years discovering where we need exec rather than write so if we switch we just start again discovering where we need write rather than exec. There seems to be no methodical way to identify exactly where these modes need to be in effect - ref JDK-8327990 which has an open PR to add in more missing transitions.