JDK-8250635 : MethodArityHistogram should use Compile_lock in favour of fancy checks
- Type: Enhancement
- Component: hotspot
- Sub-Component: compiler
- Affected Version: 11,16
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2020-07-27
- Updated: 2024-11-22
- Resolved: 2020-09-23
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 11 | JDK 16 |
|---|---|
| 11.0.12Fixed | 16 b18Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
Back in 2018, JDK-8209588, and shortly after, JDK-8209950 was filed. The remedy to the observed SIGSEGV was to call a method which would use heuristics, guided by prior observations, to find out if the storage at hand was safe to be interpreted a nmethod object. Meanwhile, further insights led to the conclusion that the Compile_lock should be held (in addition to the CodeCache_lock) while constructing the MethodArityHistogram. Holding that additional lock would make it obsolete to rely on heuristics.
Comments
|