From manavjeet18295 at iiitd.ac.in  Fri Sep 11 18:24:10 2020
From: manavjeet18295 at iiitd.ac.in (Manavjeet Singh)
Date: Fri, 11 Sep 2020 23:54:10 +0530
Subject: [jmm-dev] Java thread dynamic memory allocation
Message-ID: <CAO+=_Qj0+Z5E_jVvK2zVidwGJc0vRrAA3MzMmb6J_52EERoNww@mail.gmail.com>

Hi!
I am currently studying GC and java memory model. From the code, I
understand that GC provides a TLAB to each thread for unsynchronized
allocation of the non-humongous objects. But I am not able to understand
what happens when a "new" operator is called in java code. Is the function
that tackles this "new" operator defined in JavaThread class or some other
routine is called.
Can you please correct me if I am assuming something wrong, and point me to
relevant functions so that I can understand better.
Thanks and regards
Manavjeet Singh
CSD Undergraduate | 2018295
Indraprastha Institute of Information Technology (IIITD)

From jeremymanson at google.com  Fri Sep 11 19:31:45 2020
From: jeremymanson at google.com (Jeremy Manson)
Date: Fri, 11 Sep 2020 12:31:45 -0700
Subject: [jmm-dev] Java thread dynamic memory allocation
In-Reply-To: <CAO+=_Qj0+Z5E_jVvK2zVidwGJc0vRrAA3MzMmb6J_52EERoNww@mail.gmail.com>
References: <CAO+=_Qj0+Z5E_jVvK2zVidwGJc0vRrAA3MzMmb6J_52EERoNww@mail.gmail.com>
Message-ID: <CAPYFHW0+0LT3Ae8n9pLbqvfASuUSue5yFioqeYhgF9605Y8-7w@mail.gmail.com>

Hi Manavjeet,

In general, the Hotspot GC dev mailing list
<https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-dev> might be a
better place for this sort of question. This is a list for discussing how
threads interact in Java.

Typically, the new operator in Java code is compiled into a new bytecode.
The new bytecode is either interpreted or compiled at runtime.  There is
therefore not necessarily a single place it is implemented.  In Hotspot (if
that's what you are looking at),  it's defined separately for each
interpreter and compiler.  The engineers take care to make sure that all of
the implementations do the same thing.  Here's the one for the interpreter
for x86
<https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/templateTable_x86.cpp#L4000>.
All
of the implementations fall through to a common slow path in
oops/instanceKlass.cpp.

If you have more questions, the experts at gc dev can help you.

Jeremy

On Fri, Sep 11, 2020 at 11:24 AM Manavjeet Singh <manavjeet18295 at iiitd.ac.in>
wrote:

> Hi!
> I am currently studying GC and java memory model. From the code, I
> understand that GC provides a TLAB to each thread for unsynchronized
> allocation of the non-humongous objects. But I am not able to understand
> what happens when a "new" operator is called in java code. Is the function
> that tackles this "new" operator defined in JavaThread class or some other
> routine is called.
> Can you please correct me if I am assuming something wrong, and point me to
> relevant functions so that I can understand better.
> Thanks and regards
> Manavjeet Singh
> CSD Undergraduate | 2018295
> Indraprastha Institute of Information Technology (IIITD)
>

From manavjeet18295 at iiitd.ac.in  Sat Sep 12 02:42:35 2020
From: manavjeet18295 at iiitd.ac.in (Manavjeet Singh)
Date: Sat, 12 Sep 2020 08:12:35 +0530
Subject: [jmm-dev] Java thread dynamic memory allocation
In-Reply-To: <CAPYFHW0+0LT3Ae8n9pLbqvfASuUSue5yFioqeYhgF9605Y8-7w@mail.gmail.com>
References: <CAO+=_Qj0+Z5E_jVvK2zVidwGJc0vRrAA3MzMmb6J_52EERoNww@mail.gmail.com>
 <CAPYFHW0+0LT3Ae8n9pLbqvfASuUSue5yFioqeYhgF9605Y8-7w@mail.gmail.com>
Message-ID: <CAO+=_Qj86HTRpbt=TOvzekWgrJ7JYhprZnAHQku8fDzxGjrEEQ@mail.gmail.com>

Thanks for the information.

On Sat, Sep 12, 2020, 1:02 AM Jeremy Manson <jeremymanson at google.com> wrote:

> Hi Manavjeet,
>
> In general, the Hotspot GC dev mailing list
> <https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-dev> might be
> a better place for this sort of question. This is a list for discussing how
> threads interact in Java.
>
> Typically, the new operator in Java code is compiled into a new bytecode.
> The new bytecode is either interpreted or compiled at runtime.  There is
> therefore not necessarily a single place it is implemented.  In Hotspot (if
> that's what you are looking at),  it's defined separately for each
> interpreter and compiler.  The engineers take care to make sure that all of
> the implementations do the same thing.  Here's the one for the
> interpreter for x86
> <https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/templateTable_x86.cpp#L4000>.  All
> of the implementations fall through to a common slow path in
> oops/instanceKlass.cpp.
>
> If you have more questions, the experts at gc dev can help you.
>
> Jeremy
>
> On Fri, Sep 11, 2020 at 11:24 AM Manavjeet Singh <
> manavjeet18295 at iiitd.ac.in> wrote:
>
>> Hi!
>> I am currently studying GC and java memory model. From the code, I
>> understand that GC provides a TLAB to each thread for unsynchronized
>> allocation of the non-humongous objects. But I am not able to understand
>> what happens when a "new" operator is called in java code. Is the function
>> that tackles this "new" operator defined in JavaThread class or some other
>> routine is called.
>> Can you please correct me if I am assuming something wrong, and point me
>> to
>> relevant functions so that I can understand better.
>> Thanks and regards
>> Manavjeet Singh
>> CSD Undergraduate | 2018295
>> Indraprastha Institute of Information Technology (IIITD)
>>
>

From boehm at acm.org  Tue Sep 29 20:18:21 2020
From: boehm at acm.org (Hans Boehm)
Date: Tue, 29 Sep 2020 13:18:21 -0700
Subject: [jmm-dev] Actual IRIW use case?
Message-ID: <CAPUmR1Z8emD=2majqhdnszQc6L2yNb0bCZJRi5n6Ck9u7DhPWw@mail.gmail.com>

I just noticed https://github.com/openjdk/jdk/pull/387 seems to claim that
hotspot internally needs to specifically enforce IRIW ordering in places. I
haven't had time to explore in detail ...

Hans

From martinrb at google.com  Wed Sep 30 05:11:14 2020
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 29 Sep 2020 22:11:14 -0700
Subject: [jmm-dev] Actual IRIW use case?
In-Reply-To: <CAPUmR1Z8emD=2majqhdnszQc6L2yNb0bCZJRi5n6Ck9u7DhPWw@mail.gmail.com>
References: <CAPUmR1Z8emD=2majqhdnszQc6L2yNb0bCZJRi5n6Ck9u7DhPWw@mail.gmail.com>
Message-ID: <CA+kOe08G1RyfY37OR1RcScPi+k+DsSco1T0YOMcTGNhs37H6ng@mail.gmail.com>

I suspect it's as simple as: the "application" is an IRIW test in jcstress.

VolatileIRIWTest.java:37:@Description("Tests the IRIW sequential consistency.")

On Tue, Sep 29, 2020 at 1:18 PM Hans Boehm <boehm at acm.org> wrote:
>
> I just noticed https://github.com/openjdk/jdk/pull/387 seems to claim that
> hotspot internally needs to specifically enforce IRIW ordering in places. I
> haven't had time to explore in detail ...
>
> Hans

From david.holmes at oracle.com  Wed Sep 30 07:13:45 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 30 Sep 2020 17:13:45 +1000
Subject: [jmm-dev] Actual IRIW use case?
In-Reply-To: <CA+kOe08G1RyfY37OR1RcScPi+k+DsSco1T0YOMcTGNhs37H6ng@mail.gmail.com>
References: <CAPUmR1Z8emD=2majqhdnszQc6L2yNb0bCZJRi5n6Ck9u7DhPWw@mail.gmail.com>
 <CA+kOe08G1RyfY37OR1RcScPi+k+DsSco1T0YOMcTGNhs37H6ng@mail.gmail.com>
Message-ID: <01da1ae6-7f87-df5f-b239-e54dc3866914@oracle.com>

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.

Cheers,
David
-----

> VolatileIRIWTest.java:37:@Description("Tests the IRIW sequential consistency.")
> 
> On Tue, Sep 29, 2020 at 1:18 PM Hans Boehm <boehm at acm.org> wrote:
>>
>> I just noticed https://github.com/openjdk/jdk/pull/387 seems to claim that
>> hotspot internally needs to specifically enforce IRIW ordering in places. I
>> haven't had time to explore in detail ...
>>
>> Hans

From aph at redhat.com  Wed Sep 30 16:07:24 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 30 Sep 2020 17:07:24 +0100
Subject: [jmm-dev] Actual IRIW use case?
In-Reply-To: <01da1ae6-7f87-df5f-b239-e54dc3866914@oracle.com>
References: <CAPUmR1Z8emD=2majqhdnszQc6L2yNb0bCZJRi5n6Ck9u7DhPWw@mail.gmail.com>
 <CA+kOe08G1RyfY37OR1RcScPi+k+DsSco1T0YOMcTGNhs37H6ng@mail.gmail.com>
 <01da1ae6-7f87-df5f-b239-e54dc3866914@oracle.com>
Message-ID: <8a1fc08d-8f1d-6118-e217-e278ec453a9d@redhat.com>

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://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From erik.osterlund at oracle.com  Wed Sep 30 19:26:23 2020
From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=)
Date: Wed, 30 Sep 2020 21:26:23 +0200
Subject: [jmm-dev] Actual IRIW use case?
In-Reply-To: <8a1fc08d-8f1d-6118-e217-e278ec453a9d@redhat.com>
References: <8a1fc08d-8f1d-6118-e217-e278ec453a9d@redhat.com>
Message-ID: <A0F88EB3-9333-4275-8DF5-AA2BF0A3F273@oracle.com>

Hi,

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.

T1:
_header = someHashCode

T2:
_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:

T3:
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:

T4:
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.

Thanks,
/Erik

> 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
>