[jmm-dev] Actual IRIW use case?

Erik Österlund erik.osterlund at oracle.com
Wed Sep 30 19:26:23 UTC 2020


I have copied in a subset of my notes on this issue from previous discussions. The concrete IRIW scenario we have is the following.

T1 installs a hashCode onto an ObjectMonitor (inflated representation), and concurrently T2 deflates the same monitor.

_header = someHashCode

_contentions = -max_jint

Depending on which store happened-before the other, the header value is either a spurious value we *must* ignore and not treat as the hashCode of the object (because if it was deflated, a new hashCode could have been installed), or it is the hashCode of the object, which *must* be respected and treated like the one single valid hashCode of the object. But on a machine susceptible to IRIW problems, there exists no way of telling which store happened-before the other, as there is no total order of accesses. The reader side looks like this:

dmw = _header
is_async_deflating = _contentions < 0 (simplified for now)

This is taken from the common-case hashCode path where we read the header, and if it has a non-zero hashCode we return it unless we are async deflating.

It is assumed by the observer threads that {dmw == someHashCode, is_async_deflating == false} implies that the write in T1 happened-before T2. And that's simply an invalid assumption, on a machine where total ordering of reads of independent writes accesses is not ensured.

There is another observer:

is_async_deflating = _contentions < 0
dmw = _header

This sequence is used by e.g. deflation helper code in ObjectMonitor::enter(), that checks if we are deflating, and if we are, it reads the header and helps installing it back into the object, like this:

if (mid->is_async_deflating()) {
    install_displaced_markword_in_object(); // dmw = _header; cas(obj->markWord, ...)

This code assumes that {is_async_deflating == true && dmw == 0} implies that deflation happened-before installation of any hashCode. This is again, not valid reasoning, due to the IRIW problem; the readers simply can't know anything about the total order of independent writes, unless the reads are interleaved by a full fence. The loads could appear to seemingly reorder w.r.t. the total order that other correctly fenced threads could prove is right. The implication is that the helper function does not see hash code installations, and helps installing back a header without hash code, despite the write installing the hash code provably happening before the deflation.

The scenario of (T1, T2, T3, T4) is now down to the tea 1:1 the same as the IRIW litmus test. The corresponding undesired result that can happen on machines susceptible to IRIW problems is: {T3::dmw == someHashCode, T3::is_async_deflating == false, T4::is_async_deflating == true, T4::dmw == 0}. The consequence is different Java threads observing different hashCodes for the same java Object, when it is concurrently deflated and locked.

Hope this helps. IRIW problems *do* exist in the real world, when you look for them. They are just hard to spot. So my advise is: look for them, and don’t assume you don’t have to because it is unlikely you will find anything. We can’t have algorithms relying on luck. Because sometimes we are not lucky.


> On 30 Sep 2020, at 18:07, Andrew Haley <aph at redhat.com> wrote:
> On 30/09/2020 08:13, David Holmes wrote:
>>> On 30/09/2020 3:11 pm, Martin Buchholz wrote:
>>> I suspect it's as simple as: the "application" is an IRIW test in jcstress.
>> No this is code in the monitor subsystem that exposes an IRIW-type 
>> situation whereby on a non-multi-copy-atomic system we need a full 
>> fence() rather than a simple loadload() barrier.
>> Erik Osterlund would have to explain the technical details, but this is 
>> VM code and nothing to do with JMM or Java-level synchronization.
> Sure, but it'd still be useful to know what the actual IRIW case is.
> Paging Erik Österlund...
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://urldefense.com/v3/__https://www.redhat.com__;!!GqivPVa7Brio!JS3S6EXey9J0TceRT4qfFxztCWUhW_GR238t9gSxyzoaN1KectbrtShgRVJe3BDp5RE$ >
> https://urldefense.com/v3/__https://keybase.io/andrewhaley__;!!GqivPVa7Brio!JS3S6EXey9J0TceRT4qfFxztCWUhW_GR238t9gSxyzoaN1KectbrtShgRVJeUQLS4WA$ 
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the jmm-dev mailing list