RFR(M): 8209420: Track membars for volatile accesses so they can be properly optimized
Andrew Dinn
adinn at redhat.com
Tue Aug 14 09:50:42 UTC 2018
On 14/08/18 09:55, Roland Westrelin wrote:
> I'm confused: what is the concern here?
>
> Do we agree that dropping barriers on non escaping objects is ok?
That is what I am worrying about.
> Is the concern that we would optimize a store out that shouldn't be
> optimized out? Or that membars would be removed where they are still
> needed?
The concern is whether membars might be removed where they are still
needed. This is not about prohibiting further re-orderings but ensuring
visibility of prior writes.
> A store has 2 membars one before, one after (unless
> support_IRIW_for_not_multiple_copy_atomic_cpu is true). So if one access
> is a volatile access and the other one is not, a barrier should be
> between the 2 stores anyway and it would prevent optimizations?
Ok, so I am still confused by how this relates to what you said earlier:
"If an object is non escaping, the memory graph is rewired (the volatile
field gets its own slice). The memory input of a volatile store to a non
escaping object is then no longer the membar. 1) to 4) may apply."
So, let's assume we are looking at the case where we have a non-escaping
object and have two successive stores, the first an unsafe putXXX and
the second a putXXXVolatile. In that case what does the graph look like?
Will memory barriers be present?
Will they be attached to the 2nd store as leading and trailing barriers?
Will the optimization be applicable to this case or does it only apply
when the first store also has associated barriers?
If the optimization does apply to this case then can we arrive at the
situation where removal of the second store and its associated barriers
leaves a single non-volatile store without any barriers?
If we get to that last case then the resulting graph would generate code
that would fail to guarantee visibility of writes prior to the first store.
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
More information about the hotspot-compiler-dev
mailing list