Read during Evacuation
Simone Bordet
simone.bordet at gmail.com
Thu Apr 4 19:38:05 UTC 2019
Hi,
On Thu, Apr 4, 2019 at 9:17 PM Roman Kennke <rkennke at redhat.com> wrote:
>
> > 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?
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 :)
Thanks!
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
More information about the shenandoah-dev
mailing list