JDK-8331012 : Undo JDK-8304725 changes after JDK-8330181
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 23
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2024-04-23
  • Updated: 2024-05-03
  • Resolved: 2024-05-03
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
tbdResolved
Related Reports
Relates :  
JDK-8330181 - Move PcDesc cache from nmethod header
Relates :  
JDK-8304725 - AsyncGetCallTrace can cause SIGBUS on M1
Description
JDK-8304725 fixed issue when calling AsyncGetCallTrace can trigger writing into the PcDescCache and causing a SIGBUS error when the current thread is not WXWrite mode on M cpu.
It happened because PcDescCache was embedded into nmethod header located together with code in CodeCache.

JDK-8330181 moves PcDescCache from nmethod header and from CodeCache. As result the code added by JDK-8304725 is not needed anymore and can be removed after JDK-8330181 is integrated.
Comments
Thank you, [~jbechberger], for explanation. I mistakenly thought it was only to avoid SIGBUS on M1. Please, close this RFE then.
02-05-2024
I just checked: The PcDescCache would be modified in the signal handler when running ASGCT-based profilers if JDK-8304725 is reverted. So although now it would not cause a SIGBUS on M1, it would still invalidate the assumption the code in signal handlers do not modify global state. Therefore I would like to keep JDK-8304725 in.
02-05-2024
I just looked, and it isn't used elsewhere. Just to understand: Does ASGCT still keep the PcDescCache unmodified with JDK-8304725 in and the check out? This was the primary reason for JDK-8304725.
02-05-2024
Yes, undoing check in nmethod.cpp is the goal. But based on original changes this check is not used anywhere else. Do we need to keep the rest of JDK-8304725 changes if they are not used?
30-04-2024
I assume that this means undoing the check in nmethod.cpp, but not the rest. I'm currently testing the code with asgct_bottom.
30-04-2024