The value being zeroed must not have any pointers. This is a change from 1.7 and is part of the requirement for the hybrid write barrier <https://gist.github.com/aclements/4b5e2758310032dbdb030d7648b5ab32> (part of making garbage collection pauses smaller).
On Friday, April 14, 2017 at 4:02:24 PM UTC-7, sam....@pinterest.com wrote: > > Hi, > > I've been looking into why some of our code wasn't resulting in the memclr > optimization originally introduced in response to > https://github.com/golang/go/issues/5373. I'm still a bit unclear on why > this happens. Here is the code that triggers the issue for me: > > > package foo > > > import ( > > "testing" > > ) > > > type Foo struct { > > H string > > A int64 > > B int64 > > C int64 > > } > > > > func BenchmarkClear4(b *testing.B) { > > > b.RunParallel(func(pb *testing.PB) { > > testFoo := make([]Foo, 100) > > for pb.Next() { > > for i := range testFoo { > > testFoo[i] = Foo{} > > } > > } > > }) > > } > > For me (go 1.8) the above snippet results in asm that doesn't make use of > memclr. On the other hand, when I comment out field C in the struct above > then the code does make use of the optimization. Similarly, when I change > the first field from string to int64, it also works. Is this expected? If > so, is there some documentation for the criteria for the optimization? > > /Sam > -- 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
