JDK-8252627 : Make it safe for JFR thread to read threadObj
- Type: Bug
- Component: hotspot
- Sub-Component: gc
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2020-09-01
- Updated: 2024-11-22
- Resolved: 2020-09-07
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 16 |
|---|
16 b15Fixed  |
Related Reports
|
Relates :
|
Description
Since the thread oop moved to OopStorage, a bug was introduced. The oop is now read with load barriers. If the JFR thread shoots a thread that holds a load barrier lock, it is stuck holding that lock. Then the JFR thread tries to read the threadObj(), which might grab the same lock. This causes a deadlock. There are also some ZGC asserts that fire, not expecting relocation to happen from an unknown non-Java thread. I had fixes for said problems in my own concurrent stack scanning branch, but forgot to point it out in the review thread for JDK-8244997.
Comments
|