runtime: implement unconditional hybrid barrier
This implements the unconditional version of the hybrid deletion write barrier, which always shades both the old and new pointer. It's unconditional for now because barriers on channel operations require checking both the source and destination stacks and we don't have a way to funnel this information into the write barrier at the moment. As part of this change, we modify the typed memclr operations introduced earlier to invoke the write barrier. This has basically no overall effect on benchmark performance. This is good, since it indicates that neither the extra shade nor the new bulk clear barriers have much effect. It also has little effect on latency. This is expected, since we haven't yet modified mark termination to take advantage of the hybrid barrier. Updates #17503. Change-Id: Iebedf84af2f0e857bd5d3a2d525f760b5cf7224b Reviewed-on: https://go-review.googlesource.com/31765Reviewed-by: Rick Hudson <rlh@golang.org>
Showing
Please register or sign in to comment