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

Andrew Haley aph at redhat.com
Wed Feb 3 15:10:31 UTC 2016


On 02/03/2016 01:42 PM, Mikael Gerdin wrote:

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

It does, thank you.  I shall try to stop worrying.  :-)

For what it's worth: in the java.util.concurrent list we often use
"fence" for memory fence instructions and "barrier" for things like GC
write barriers.


More information about the hotspot-compiler-dev mailing list