On Saturday, April 15, 2017 at 7:18:51 PM UTC+8, Konstantin Khomoutov wrote: > > On Sat, 15 Apr 2017 01:31:27 -0700 (PDT) > "'Keith Randall' via golang-nuts" <golan...@googlegroups.com <javascript:>> > wrote: > > > > 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. > [...] > > > type Foo struct { > > > H string > > > A int64 > > > B int64 > > > C int64 > > > } > [...] > > > 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. > [...] > > 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). > > Sorry, I might be missing the point completely but while this perfectly > explains using of the memclr optimization after removal of H but how > can it explain also enabling of memclr after removal of C which is not > a pointer? >
Looks if H is present, it will optimized as memclrHasPointers, otherwise, it will optimized as memclrNoHeapPointers. But it is really weird that not optimization made if C is present. -- 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.
