Release store in C2 putfield

[Andrew Haley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/03/2014 07:10 PM, Aleksey Shipilev wrote:
> On 09/03/2014 10:02 PM, Andrew Haley wrote:
>> On 09/03/2014 06:47 PM, Aleksey Shipilev wrote:
>>> On 09/03/2014 09:00 PM, Andrew Haley wrote:
>>>> On 09/03/2014 05:49 PM, Aleksey Shipilev wrote:
>>>>> Why is a simple store is sufficient here for AArch64? Do the stores ordered on AArch64 (I thought not)? I thought the "RC" part in "RCsc" only applies to explicit synchronization instructions.
>>>> 
>>>> I discussed this with Peter Sewell, and it's explained in his (co-authored) paper "A Tutorial Introduction to the ARM and POWER Relaxed Memory Models" at http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf in Section 4.1, "Enforcing Order with Dependencies"
>>>> 
>>>> In the AArch64 spec, we have:
>>>> 
>>>> B2.7.2  Ordering requirements
>>>> 
>>>> If an address dependency exists between two reads or between a read and a write, then those memory accesses are observed in program order by all observers within the shareability domain of the memory
>>>> 
>>>> So, an address dependency and a DMB when an object is created is all we need.
>>> 
>>> Okay, I read that paper from Sewell et al. before. I don't quite believe this is about "reading" the constructed objects, and so I don't see how address dependencies are applicable here.
>> 
>> IMO the case he describes is exactly the case we're talking about: there is an address dependency between a write which stores the address of an object and another thread which reads that stored address and uses it to form a field reference.
> 
> Nope. Address dependency is between the *read* of the object reference, and the field read which uses the value from the first read. There is no address dependency between the write and the read. To quote the paper: "There is an address dependency from a read instruction to a program-order-later read or write instruction when the value read by the first is used to compute the address used for the second."

Well alright, the address dependency is indeed between the read of an
object reference and the later use of it to form an address, but it
seems to me that the example in 4.1 is almost exactly our case, and
the Forbidden state is exactly what the JMM says we mustn't see.

> I understand what you meant, but that's for the *consumer* side. put_xxx seems to be a *producer* side, and address dependencies are not applicable here.
> 
>>> then it is as well fine for all other architectures (except Alpha)...
>> 
>> I think so, but I'm only sure about AArch64.
> 
> So there, let's figure out whether we should just purge the entire block! :)

Okay.  It's better than arguing about interpretation of the paper.

Andrew.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iQEcBAEBCAAGBQJUB10zAAoJEKXNYDUzL6Zx4PYIAJGAx70hKX+qNEYRWfs5CLJl
1Nfx81xPWvPaqHzIqyjQoPShSHUZD+9MQDghAnmF/V6l0fJFesstTrwVbJ2SfLsN
Q08JD/pzsklRpVxIIA72zrA0cbc0bq+H6rivrOqFroBPaaXlldnv9yz9XBCpsuYu
xIopDBYyb+PNvyzkUfKp+fwpWLbuzVZ8jMIMpphH38GlBbbHH8K6MnLRpjJmc4kC
c6CI6GvzHZvHELoQCTNXXJK+RHo3NEwAnku/NlO9n1z+Bh6Z4kD65BwILROaPUHc
y8uTO6jiJFXN68NQs25cuVV5F0wc4szbrUHNzoPdLOQsCO0DuWHs+x43WoFt0yU=
=SgTQ
-----END PGP SIGNATURE-----