RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1

Mikael Gerdin mikael.gerdin at oracle.com
Wed Feb 3 13:42:07 UTC 2016

Hi Andrew,

On 2016-02-02 18:03, Andrew Haley wrote:
> On 02/02/2016 02:55 PM, Mikael Gerdin wrote:
>> The barrier can only be removed if the object is never allocated.
>> If the object is allocated and the field store is performed then the
>> barrier must be preserved, even if the compiler can prove that no
>> application thread can see the objects, a concurrent gc thread may still
>> see these objects.
> This reminds me of the discussion at http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020345.html

I've realized that this is becoming a bit confusing since we are in fact 
talking about two different uses of the word "barrier".

The use I meant in my reply above is the entire "g1 post-barrier".
This is further complicated by the fact that the "g1 post-barrier" does 
contain an instruction sequence which has the intended effect of a 
"StoreLoad memory barrier".

I've had a look at the mail thread (and I did follow it with a cursory 
look when it was active).

> It removes the memory barrier after object creation if the object does
> not escape.  I guess this is not safe, then, because a concurrent GC
> will see a partially-constructed object: the fields may not have been
> zeroed and the  header may not have been initialized.
> I'd like your opinion on this.

I think that the reasoning in the thread is sound, and it should hold 
for this case as well.

The one question I have is if it is possible for a safepoint to occur 
*) in your case between the object initialization and the memory barrier 
*) in this case between the object allocation and the field store with 
its g1 post-barrier.

If there is no way a safepoint can occur in the middle of these 
transactions then I believe it should be safe to elide the entire "g1 
post-barrier" in this case. But the reason for that is that post 
barriers can be elided altogether for newly allocated objects.
This, however, should already be taken care of by

So, given that we are emitting the "g1 post-barrier" I would say that 
it's not safe to remove the "memory barrier" instruction from it.

Does that make sense?


> Thanks,
> Andrew.

More information about the hotspot-compiler-dev mailing list