<p dir="ltr">You're right Thomas, I was mistakenly looking at release_store_ptr_*fence* - all good then.</p>
<p dir="ltr">Yes, it sounds like it would break on alpha (based on your description, I haven't looked at the code), but that's not a supported platform anyway right? Otherwise, you'd probably have to introduce a new read barrier type for data dependence that's a nop for all but alpha so as to not penalize the others.</p>
<p dir="ltr">sent from my phone</p>
<div class="gmail_quote">On May 13, 2015 6:10 PM, "Thomas Schatzl" <<a href="mailto:thomas.schatzl@oracle.com">thomas.schatzl@oracle.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On Wed, 2015-05-13 at 17:22 -0400, Vitaly Davidovich wrote:<br>
> Isn't this going to emit a full fence on x86/64? Is storestore<br>
> insufficient?<br>
<br>
release_store_ptr is a storestore.<br>
><br>
> Also, is the load side ordered properly already?<br>
<br>
On the load side the code depends on data dependency ordering, i.e. the<br>
values we put in there and expect to be visible before the write in the<br>
release_store is/can only be accessed via that pointer.<br>
<br>
That data structure that is released by the release_store() is a private<br>
data structure allocated/used just by this thread before the<br>
release_store.<br>
<br>
So the new code is broken on Alpha, but seems good on everything else.<br>
<br>
The concurrent reader is in HeapRegionRemSet::find_region_table().<br>
<br>
Please have a look, maybe when it has originally been reviewed<br>
internally long time ago something has been overlooked (and is now by<br>
me).<br>
<br>
Thanks,<br>
  Thomas<br>
<br>
<br>
</blockquote></div>