Release store in C2 putfield
martin.doerr at sap.com
Thu Sep 4 10:00:00 UTC 2014
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.
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
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