Description
I did a quick and dirty instrumentation of writebarrierptr and found that when executing cmd/compile to build std, about 25% of calls on average had *dst == src. In that case, there's no need to do the actual assignment or gray any objects (I think). I don't know how (a)typical that 25% number is.
We should investigate whether checking for this and short-circuiting is a net performance gain, in general. There are multiple places in the stack this could occur:
(1) writebarrierptr (and friends)
Add
if *dst == src {
return
}to the beginning of the method.
(2) Wrapper routines
Add checks like:
if dst[1] != src[1] {
writebarrierptr(&dst[1], src[1])
}to the runtime routines that call writebarrierptr, like the wbfat.go routines, and writebarrierstring and friends. This is different than (1) insofar as it skips the writebarrierptr function call instead of having it return immediately.
(3) Generated code
We currently generate wb-calling code like:
if writeBarrier.enabled {
writebarrierptr(dst, src)
} else {
*dst = src
}We could instead generate code like:
if *dst != src {
if writeBarrier.enabled {
writebarrierptr(dst, src)
} else {
*dst = src
}
}I don't plan to work on this soon, as I need to undistract myself.