RFR: Factor out storeval barrier from read barriers

[Roman Kennke]

More precisely, the purpose of the read barrier is to ensure consistency with preceding writes, i.e. we must not read from a to-space object if a preciding write has written to a to-space copy. This is done by resolving the field-holding object's brooks pointer and read from there.

The purpose of the storeval barrier is to avoid races with gc threads during the update references phase: we might write a to-space ref into a field that had already been updated and will therefore not be seen again by the updating thread. We must ensure that the written reference points to to-space. Since update-refs happens in a separate phase after evacuation, it is sufficient to resolve the store val by a read barrier. Notice also that this may optimize better than other read-barriers: e.g. storrval barriers may be re-ordered with related write barriers.

In the upcoming concurrent partial GC work, we evac and update during the same phase. This means that a read-barrier is *not* sufficient to ensure only to-space refs for storevals. We need an evacuting write barrier now. That's the motivation for this patch.

Does that make sense?

Roman

Am 28. August 2017 15:07:14 MESZ schrieb Aleksey Shipilev <shade at redhat.com>:
>On 08/28/2017 01:53 PM, Zhengyu Gu wrote:
>> May I ask why it calls "StoreValBarrier"? while it seems to only deal
>with read.
>
>It is a barrier on a "stored value", which is different from our
>regular read barrier that covers
>the "values read from heap".
>
>-Aleksey

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.