I'll try, I'm not sure what the actual question is so here is a high level
First some terminology.
Black objects are objects that are reachable from roots and have been
Grey objects are object that are reachable from roots that need to be
White objects are objects that have not been encountered by the marker.
Slots are fields in an object holding a pointer, sometimes called a pointer
The job of the write barrier is maintain the invariant that black objects
never point to white objects. If one is about to place a pointer to a white
object into a black object's slot it must first turn the white object into
a grey object. It does this by marking the white object and adding it to a
wbuf where it will be scanned.
Once the wbufs are empty and there are no grey objects then the remaining
white objects are made available for reuse.
As an optimization the write barrier contains a conditional so that if the
GC is not running the write barrier simply returns.
I am not sure what you mean by rescan pointers. An object starts out white,
if it is reached and not marked it is marked and placed in a wbuf
indicating that it is grey. It is then removed from the wbuf and scanned
indicating that it is black. Once it is marked it stays marked. Once the
wbufs are empty there are no grey objects, only black and white objects.
The correctness and completeness proofs follow those found in Sapphire:
Copying GC Without Stopping the World <Sapphire: Copying GC without
Stopping the World>. The Go GC algorithm is based on the non-copying
portions of Sapphire which in turn is based on Dijkstra's earlier work.
I'm not sure what you are trying to accomplish but I hope this helps.
On Thu, May 12, 2016 at 4:47 PM, Ian Lance Taylor wrote:
[ +rlh, +austin ]
On Thu, May 12, 2016 at 10:21 AM, wrote:
can you please explain more deeply than in mbarrier document, how do
barriers work? Do they always execute when mutator tries to access white
pointers or not? If so, why do we need to rescan pointers? Or this process
is stopped when partial wbufs are analyzed?
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.