Release store in C2 putfield

[Bertrand Delsart]

I'm not a C2 expert but from what I have quickly checked, an issue may 
be that we need StoreStore ordering on some platforms.

This should for instance be true for cardmarking (new stored oop must be 
visible before the card is marked). This may also be true for the oop 
stores in general, as initially discussed. [IMHO this is related to 
final fields, which have to be visible when the object escape. Barriers 
are the end of the constructors may not be sufficient if objects can can 
escape before the end of their init() method. Systematic StoreStore 
barriers on oop_store are an easy way to solve the issue without escape 
analysis].

Unfortunately, MemNode only defines higher level 'release' and 
'acquire'. This means that if you want to use MemNode to guarantee the 
StoreStore (instead of using a separate membar), then you need to use 
MemNode::release... which uselessly adds the LoadStore semantic.

LoadStore may require a stronger barrier (for instance "DMB SY" instead 
of "DMB ST" on ARM32).

We have the same issue with some other code in hotspot. Some StoreStore 
constraints just before a write have been implemented using 
OrderAccess::release_store(). The later is currently slightly more 
efficient on SPARC/x86... but this is because OrderAccess::storestore() 
is not fully optimized (we just need to prevent C++ compiler reordering, 
we should not have to actually generate code for storestore on TSO 
systems). Unfortunately, on platforms with weaker memory models, 
release_store() may be less efficient than a storestore() followed by a 
write :-(

May be we need in OrderAccess and in MemNode a new store operation 
weaker than release_store, ordering only the store wrt previous stores 
(e.g. "membar #StoreStore; write"). This will be a simple store on TSO 
systems (+ something to prevent compiler reordering) but will be 
expanded to whatever is the most efficient barrier on the other systems.

Regards,

Bertrand.

On 03/09/14 20:58, Andrew Haley wrote:
> On 09/03/2014 07:29 PM, Aleksey Shipilev wrote:
>> On 09/03/2014 10:25 PM, Andrew Haley wrote:
>>> On 09/03/2014 07:10 PM, Aleksey Shipilev wrote:
>>>> 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.
>>
>> Let's wait a bit for Goetz's input on this. It was his commit that introduced this in the first place:
>>
>> $ hg log -r 5983 changeset:   5983:2113136690bc parent:      5981:eb178e97560c user:        goetz date:        Fri Nov 15 11:05:32 2013 -0800 summary:     8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering
>>
>> We can dig in the mail history if Goetz does not reply any time soon.
>
> Okay.  While we're discussing this, I'd better tell you that I am also
> looking at why the card table write is a release store.  But that's for
> later.
>
> Andrew.
>


-- 
Bertrand Delsart,                     Grenoble Engineering Center
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38334 Saint Ismier,                                        FRANCE
bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~