JDK-8330171 : Lazy W^X switch implementation
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2024-04-12
  • Updated: 2024-07-24
  • Resolved: 2024-07-24
Related Reports
Duplicate :  
JDK-8330169 - Lazy W^X swtich implementation
Duplicate :  
JDK-8330170 - Lazy W^X swtich implementation
Duplicate :  
JDK-8330167 - Lazy W^X swtich implementation
Duplicate :  
JDK-8330168 - Lazy W^X swtich implementation
Relates :  
JDK-8302736 - Major performance regression in Math.log on aarch64
Relates :  
JDK-8307549 - AsyncGetCallTrace crashes on Mac M1 after JDK-8294160
Relates :  
JDK-8304725 - AsyncGetCallTrace can cause SIGBUS on M1
Relates :  
JDK-8327036 - [macosx-aarch64] SIGBUS in MarkActivationClosure::do_code_blob reached from Unsafe_CopySwapMemory0
Relates :  
JDK-8307817 - AARCH64: make macOS W^X locking more fine grained
Description
"With the porting of the JDK to macOS/AArch64 (JEP-391), the JVM codebase has received numerous patches aimed at addressing the write-xor-execute (W^X) policy issue. Currently, the approach to handling this problem involves a trial-and-error method, where the ThreadWX guard is set at each entry point where the JVM crashes. At times, it is even simpler to disable a specific feature (JDK-8311636) than to resolve the issue.

An alternative approach could involve dynamically switching the W^X thread mode as needed. We have conducted tests and found no performance degradation."
Comments
RT Triage: this is being addressed in JDK-8307817.
24-07-2024
Duplicated records is caused by my home network glitch.
12-04-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18762 Date: 2024-04-12 14:40:05 +0000
12-04-2024