RFR: JDK-8035496: G1 ARM: missing remset entry noticed by VerifyAfterGC for vm/gc/concurrent/lp50yp10rp70mr30st0

Vitaly Davidovich vitalyd at gmail.com
Wed May 13 22:27:06 UTC 2015


You're right Thomas, I was mistakenly looking at release_store_ptr_*fence*
- all good then.

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.

sent from my phone
On May 13, 2015 6:10 PM, "Thomas Schatzl" <thomas.schatzl at oracle.com> wrote:

> Hi,
>
> On Wed, 2015-05-13 at 17:22 -0400, Vitaly Davidovich wrote:
> > Isn't this going to emit a full fence on x86/64? Is storestore
> > insufficient?
>
> release_store_ptr is a storestore.
> >
> > Also, is the load side ordered properly already?
>
> On the load side the code depends on data dependency ordering, i.e. the
> values we put in there and expect to be visible before the write in the
> release_store is/can only be accessed via that pointer.
>
> That data structure that is released by the release_store() is a private
> data structure allocated/used just by this thread before the
> release_store.
>
> So the new code is broken on Alpha, but seems good on everything else.
>
> The concurrent reader is in HeapRegionRemSet::find_region_table().
>
> Please have a look, maybe when it has originally been reviewed
> internally long time ago something has been overlooked (and is now by
> me).
>
> Thanks,
>   Thomas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20150513/2eadcb72/attachment.html>


More information about the hotspot-gc-dev mailing list