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
Hi,
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.
OK.
> 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.
Andrew.
More information about the hotspot-compiler-dev
mailing list