Read during Evacuation

[Roman Kennke]

>>> while studying a bit Shenandoah, I would like to ask your help about
>>> how reads are handled in case of a concurrent evacuation, the
>>> following case:
>>>
>>> * Mutator1 reads the fwd_ptr of an object, points to self.
>>> * Mutator2 wants to write to the same object, but GC is in the evacuation phase.
>>> * Mutator2 evacuates the object, CASes the fwd_ptr, updates the field
>>> it wants to write and let's assume that this is a volatile write.
>>> * Mutator1 resumes and follows the old fwd_ptr, and reads a stale value.
>>>
>>> How can Mutator1 know that the object has been evacuated _and_ changed?
>>
>> This is a race, with or without Shenandoah. Shenandoah cannot fix that race.
> 
> What if Mutator2 is instead a GC thread?

A GC thread wouldn't mess with any data that Mutator 1 is trying to read.

> Wouldn't a read barrier that performs the evacuation solve the issue?
> The read would be guaranteed to happen in the to-space object and the
> loser thread would discard its copy.
> 
> I am sure I am missing something here :)

In the absence of synchronization, there is still no guarantee what 
Mutator1 would read. Mutator 2 might update the field, but Mutator 1 
might read his cached copy.

Roman