-
Enhancement
-
Resolution: Fixed
-
P4
-
11, 16
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8265269 | 11.0.12 | Lutz Schmidt | P4 | Resolved | Fixed | b01 |
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.
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.
- backported by
-
JDK-8265269 MethodArityHistogram should use Compile_lock in favour of fancy checks
-
- Resolved
-
- relates to
-
JDK-8209950 SIGBUS in CodeHeapState::print_names()
-
- Resolved
-
-
-
- Resolved
-
