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

[Mikael Gerdin]

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 
between
*) in your case between the object initialization and the memory barrier 
instruction
*) 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
GraphKit::g1_can_remove_post_barrier.

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?

/Mikael


>
> Thanks,
>
> Andrew.
>