RFR(M): 8209420: Track membars for volatile accesses so they can be properly optimized
Roland Westrelin
rwestrel at redhat.com
Tue Aug 14 08:55:42 UTC 2018
Hi Andrew,
> Ok, so that means you can have two successive stores to the same field
> and if we get here we know the second one has associated memory
> barriers. What guarantees that the first one will also have memory
> barriers? Obviously, the field may itself be declared as volatile and
> this code may arise from a standard putfield. However, what about the
> case where the field might be written firstly using Unsafe.putXXX and
> then using Unsafe.putXXXVolatile? Is that not possible?
I'm confused: what is the concern here?
Do we agree that dropping barriers on non escaping objects is ok?
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?
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?
Roland.
More information about the hotspot-compiler-dev
mailing list