RFR(M) 8138894: C1: Support IRIW on weak memory platforms

[Doerr, Martin]

Hi Hui Shi,

I appreciate that aarch64 experts are interested in this topic as well.

Here are my answers to your questions:
> why volatile field write only in initializer method requires memory barrier?

As explained earlier, we don’t emit any membar instructions after volatile stores by default if IRIW support is enabled.
(The Java memory model compliant ordering of volatile accesses is fulfilled by the membar scheme described below.)
This leads to the behavior of the following example.
We initialize an AtomicInteger (which contains a volatile int) and publish it to another thread. This thread may observe 0 instead of the init value.

As far as I know, this behavior is allowed by the Java memory model. However, we think that it is undesired.
There was also a Concurrency Torture Test which flagged this as error.

The short answer is, it may not be strictly necessary, but it could otherwise be unexpected for Java developers.


> If volatile field is written in initializer, but volatile field isn't initialized object's field, does it need memory barrier?
I don’t think there’s any undesired behavior in this case. So it should not be needed. Anyway, I don’t think this case is worth optimizing for C1.
This change makes C1 support IRIW in the same way as C2.


If you’re thinking about using it on aarch64 there may be a desire to refine the implementation.
If I remember correctly, aarch64 is also CPU_NOT_MULTIPLE_COPY_ATOMIC, but has some instructions which behave multiple copy atomic.

Best regards,
  Martin

From: Hui Shi [mailto:hui.shi at linaro.org]
Sent: Freitag, 9. Oktober 2015 15:11
To: Doerr, Martin
Subject: Re: RFR(M) 8138894: C1: Support IRIW on weak memory platforms

Hi Martin,

I'm interested in PPC insert memory barrier when volatile field is wrote in initializer method.
why volatile field write only in initializer method requires memory barrier?

If volatile field is written in initializer, but volatile field isn't initialized object's field, does it need memory barrier? For example  written b's volatile field in A's initializer.

class A {
   A(B b) { b.vol = 1; }
}

class B { int vol = 0; }

Regards
Shi Hui

On 9 October 2015 at 05:46, Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:
Hi,


Some time ago, we implemented support for ordering of "Independent Reads of Independent Writes" in the template interpreter and C2 Compiler for PPC64. However, it needs to be consistent with C1.



Without "IRIW" support, we generate load-acquire for volatile loads and release-store-fence for volatile stores.

With "IRIW" support, we generate fence-load-acquire for volatile loads and release-store for volatile stores.

CPU_NOT_MULTIPLE_COPY_ATOMIC is currently only defined on PPC64 (though it may be interesting for aarch64 as well).

This change is a prerequisite for our C1 on PPC64 contribution.



Webrev is here:

http://cr.openjdk.java.net/~mdoerr/8138894_c1_IRIW/webrev.00



Please review this change.  I need a sponsor, please.


Best regards,
  Martin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151009/25865644/attachment-0001.html>