-
Bug
-
Resolution: Fixed
-
P3
-
15
-
b33
-
arm, ppc
-
linux
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8249557 | 16 | Daniel Daugherty | P3 | Resolved | Fixed | b07 |
JDK-8250192 | 15.0.2 | Daniel Daugherty | P3 | Resolved | Fixed | b01 |
JDK-8250491 | 15.0.1 | Daniel Daugherty | P3 | Resolved | Fixed | b03 |
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
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
- backported by
-
JDK-8249557 more fencing needed in async deflation for non-TSO machines
-
- Resolved
-
-
JDK-8250192 more fencing needed in async deflation for non-TSO machines
-
- Resolved
-
-
JDK-8250491 more fencing needed in async deflation for non-TSO machines
-
- Resolved
-
- relates to
-
JDK-8153224 Monitor deflation prolong safepoints
-
- Resolved
-