JDK-8328306 : Allow VM to run with X memory execute by default
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 23
  • Priority: P4
  • Status: In Progress
  • Resolution: Unresolved
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2024-03-16
  • Updated: 2024-05-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8327860 - Java processes get killed, leaving no hs_err/stack trace on macOS 14.4
Relates :  
JDK-8263492 - [macos_aarch64] Consider moving W^X state to JavaThread
Relates :  
JDK-8329748 - Change default value of AssertWXAtThreadSync to true
Relates :  
JDK-8307817 - AARCH64: make macOS W^X locking more fine grained
Description
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.
Comments
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.
19-03-2024
Though looking at JDK-8307817 it seems there is a similar view there. But it still requires careful identification on the code that needs write access and the patterns of usage.
19-03-2024
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
18-03-2024
Also you need to discuss with the original porting team why they chose the current approach - ref JDK-8253795.
18-03-2024
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.
17-03-2024