JDK-8266742 : Check W^X state on possible safepoint
- Type: Enhancement
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 17
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- OS: os_x
- CPU: aarch64
- Submitted: 2021-05-07
- Updated: 2022-02-10
- Resolved: 2021-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.
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.
| JDK 17 |
|---|
17 b23Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
There is a class of possible issues on macos/aarch64 related to W^X management, when the switch between modes is performed near JavaThread state change (java/native/vm). Thread state change checks for safepoint and sometimes this check leads to actual safepoint, where we may need WXWrite mode (e.g. making method non-entrant needs to poison nmethod instructions). So in general, java thread state should always be changed in WXWrite mode and before going to WXExec. Failing to do that leads to rare and hard to reproduce crashes. This enhancement suggests to add explicit check of the WX mode to catch such issues in advance.
Comments
|