Release store in C2 putfield

[Doerr, Martin]

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.

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.