• Austin Clements's avatar
    runtime: ensure GC sees type-safe memory on weak machines · f5d494bb
    Austin Clements authored
    Currently its possible for the garbage collector to observe
    uninitialized memory or stale heap bitmap bits on weakly ordered
    architectures such as ARM and PPC. On such architectures, the stores
    that zero newly allocated memory and initialize its heap bitmap may
    move after a store in user code that makes the allocated object
    observable by the garbage collector.
    
    To fix this, add a "publication barrier" (also known as an "export
    barrier") before returning from mallocgc. This is a store/store
    barrier that ensures any write done by user code that makes the
    returned object observable to the garbage collector will be ordered
    after the initialization performed by mallocgc. No barrier is
    necessary on the reading side because of the data dependency between
    loading the pointer and loading the contents of the object.
    
    Fixes one of the issues raised in #9984.
    
    Change-Id: Ia3d96ad9c5fc7f4d342f5e05ec0ceae700cd17c8
    Reviewed-on: https://go-review.googlesource.com/11083Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
    Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
    Reviewed-by: 's avatarMinux Ma <minux@golang.org>
    Reviewed-by: 's avatarMartin Capitanio <capnm9@gmail.com>
    Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
    f5d494bb
atomic_arm64.s 2.27 KB