RFR(M): 8209420: Track membars for volatile accesses so they can be properly optimized

[Andrew Dinn]

Hi Roland,

On 14/08/18 09:07, Roland Westrelin wrote:
   . . .
>> This looks fine when dealing with stores to non-volatile fields but I
>> don't follow how it works when writing to volatile fields.
> 
> 1) to 4) above only apply to non volatile fields unless the field's
> object is non escaping, in which case they also apply to volatile
> fields. For a volatile store, the store's memory input is a projection
> of a membar. All transformations expect a particular memory input that
> can't be a membar. So they are not applied to volatile fields. 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.

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 could add an assert to check that we're dropping membars only for non
> escaping objects.
Yes, that would probably be a good idea.

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