JDK-8247280 : more fencing needed in async deflation for non-TSO machines
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 15
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- OS: linux
- CPU: arm,ppc
- Submitted: 2020-06-09
- Updated: 2024-10-17
- Resolved: 2020-07-15
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 15 | JDK 16 |
|---|---|
15 b33Fixed  |
16Fixed |
Related Reports
|
Relates :
|
Description
Erik O. sent more mullings on the recent JDK-8153224 bits: On 6/4/20 5:36 AM, Erik Österlund wrote: > Hi Dan, > > ObjectMonitor::set_allocation_state needs a release_store, and ObjectMonitor::allocation_state > needs a load_acquire, instead of plain loads and stores. In particular the is_old() function > used by the service thread to check if we should deflate, should probably use load_acquire. > > The reasoning is that the service thread checks if allocation_state() is old, and assumes that > values read from the monitor/markWord will not be stale values from before the monitor was initialized > as being bound to the new object. In particular, I am worried that the store of the markWord pointing > at the monitor, and the store publishing it as old, get reordered. Then, a concurrent deflation thread > could consider the monitor a candidate for deflation, before the markWord of the object has been > linked to the ObjectMonitor. > > On TSO machines, this won't matter, but on other machines it will (AArch64 and PPC). > > I'm not quite sure if anything more serious than a memory leak will happen in this rather narrow > race condition (the deflation fails and never gets considered for deflation again, as the monitor > is left in an unexpected state). Nevertheless, I think we should fix it. > > Sorry I didn't catch this during the review. > > /Erik
Comments
|