Release store in C2 putfield

[David Holmes]

On 4/09/2014 8:00 PM, Doerr, Martin wrote:
> Hi Andrew,
>
> the problem on IA64 is that there's no separate release memory barrier.
> Issuing a full fence after every object creation is more expensive than releasing all oop stores.
> This might be different on AArch64 where other memory barriers are available.
> I'd appreciate a proposal how we can support both ways.

I would think an abstraction to represent each special context. One will 
be a no-op on IA64, the other a no-op on AArch64. Though I think what we 
are highlighting here is that shared C2 abstractions do not fit when we 
want to optimize for specific architectures. A way to redefine this code 
in a platform specific file may be a better long term solution.

I'll also add that a "barrier" at the end of construction is not 
necessarily sufficient as Bertrand has already mentioned, if 'this' can 
escape.

David

> Best regards,
> Martin
>
> -----Original Message-----
> From: Andrew Haley [mailto:aph at redhat.com]
> Sent: Donnerstag, 4. September 2014 11:45
> To: Doerr, Martin; Volker Simonis; Vladimir Kozlov
> Cc: hotspot-dev Source Developers; Lindenmaier, Goetz
> Subject: Re: Release store in C2 putfield
>
> Hi,
>
> On 09/04/2014 10:29 AM, Doerr, Martin wrote:
>
>> got it. You want to use releasing stores on AArch64 like we do it on IA64.
>>
>> We exploit that the releasing stores perform better than separate
>> memory barrier instructions on IA64.
>> That's why we implemented the MemBarRelease and MemBarStoreStore as
>> empty nodes and rely on the release flag of the store nodes.
>
> Okay.
>
>> The release flag for volatile store replaces the MemBarRelease and
>> the release_if_reference case replaces the MemBarStoreStore which is
>> needed to make the object initialization visible for other threads
>> like GC. In other words, we skip the separate memory barriers and
>> release all oop stores.
>
> Right.  But the thing I'm complaining about is the release store on
> every putfield, regardless of whether it's volatile.  That's surely
> wrong.  It has a performance hit.  I'm sure IA64 would be better
> without it, too.
>
>> I'm not familiar with AArch64. Don't you want to implement the 2
>> nodes with empty encoding?
>
> No, because I want (and I'm sure we all want) a memory barrier at the
> end of object creation.  Then we don't need one on every putfield.
>
>> The ARM memory model is similar to PPC where we definitely need
>> release barriers.
>
>> I've read parts of the email thread in which you were citing "A
>> Tutorial Introduction to the ARM and POWER Relaxed Memory Models",
>> but I've only seen explanations about the ordering on the reader's
>> side. I agree with that the reader of the oop doesn't need barriers.
>
> That's true, as long as there is a store barrier when an object is
> created.
>
>> But how do you ensure that the writer "publishes" the initializing
>> stores before the oop store?
>
> I have a store barrier when the object is created: that's correct.
>
> Andrew.
>