• Austin Clements's avatar
    runtime: perform write barrier before pointer write · 8f81dfe8
    Austin Clements authored
    Currently, we perform write barriers after performing pointer writes.
    At the moment, it simply doesn't matter what order this happens in, as
    long as they appear atomic to GC. But both the hybrid barrier and ROC
    are going to require a pre-write write barrier.
    
    For the hybrid barrier, this is important because the barrier needs to
    observe both the current value of the slot and the value that will be
    written to it. (Alternatively, the caller could do the write and pass
    in the old value, but it seems easier and more useful to just swap the
    order of the barrier and the write.)
    
    For ROC, this is necessary because, if the pointer write is going to
    make the pointer reachable to some goroutine that it currently is not
    visible to, the garbage collector must take some special action before
    that pointer becomes more broadly visible.
    
    This commits swaps pointer writes around so the write barrier occurs
    before the pointer write.
    
    The main subtlety here is bulk memory writes. Currently, these copy to
    the destination first and then use the pointer bitmap of the
    destination to find the copied pointers and invoke the write barrier.
    This is necessary because the source may not have a pointer bitmap. To
    handle these, we pass both the source and the destination to the bulk
    memory barrier, which uses the pointer bitmap of the destination, but
    reads the pointer values from the source.
    
    Updates #17503.
    
    Change-Id: I78ecc0c5c94ee81c29019c305b3d232069294a55
    Reviewed-on: https://go-review.googlesource.com/31763Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
    8f81dfe8
chan.go 18.2 KB