Release store in C2 putfield

Andrew Haley aph at
Thu Sep 4 09:45:14 UTC 2014


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.


> 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

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


More information about the hotspot-dev mailing list