JDK-8263492 : [macos_aarch64] Consider moving W^X state to JavaThread
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 17
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2021-03-12
  • Updated: 2024-05-17
  • Resolved: 2024-01-11
Related Reports
Relates :  
Relates :  
Description
https://github.com/openjdk/jdk/pull/2200/files/0d0e9baf0580f6fb0b4750e5fc709ac214acc488#r572711753

https://mail.openjdk.org/pipermail/core-libs-dev/2021-March/075310.html

As reasonably pointed, W^X thread state management could be moved to os_cpu/thread_bsd_aarch64.hpp. But now non-JavaThread's also rely on the management.
Comments
Runtime Triage: This is not on our current list of priorities. We will consider this feature if we receive additional customer requirements.
11-01-2024

W^X thread state management doesn't seem to have a query function, so it might make sense to hold keep the state in Thread and not JavaThread. I made the suggested changes and fail runtime/signal/ tests because the signal handler isn't run for one of the cases. // signal handler BEFORE VM initialization AND // Invoke signal AFTER VM exits void scen_prepost() { setSignalHandler(); initVM(); (*vm)->DestroyJavaVM(vm); invokeSignal(); } I toggled setting the state to WXExec and WXWrite at the end of DestroyJavaVM but neither works.
29-03-2023

[~akozlov], Is that enough to move the corresponding files to the os_cpu folder?
04-11-2022

I've updated the description with https://mail.openjdk.org/pipermail/core-libs-dev/2021-March/075310.html The idea is to leverage an existing infra of injecting platform members to thread. Unfortunately, the infra is implemented only for JavaThreads. So the suggestion was to use existing W^X management for JavaThreads only; and make the management of the rest of the threads more simple e.g. be make it always WXWrite.
04-11-2022