You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have read the comments in slicelit, but I didn't find any operations that can generate such stores. As far as I know, pointers to stack objects cannot be stored in global objects. So is this a compiler bug? Or the Go compiler does this on purpose to achieve some optimization I don't know yet?
Go1.19.5 and Go1.20.6 share the above pattern, allocating all arrays on stack.
And I notice that in Go 1.18 Release Notes, "The garbage collector now includes non-heap sources of garbage collector work". Does the change of GC in Go1.18 affect the strategy of allocating small array?
I think the compiler is trying to cache the allocations of the static slice literals however it also for some reason it does not generate the code to do anything with the cached slices, it always recreates on each iteration even if you leak them on purpose.
That is if anything a performance bug, since this creates a bunch of writes into globals which add writebarriers for no reason.
The only read of theses globals is in the same place they are written to fill in the writebarrier's buffer.
I'm not sure why the compiler is somehow deciding it should generate caches but not use them.
Either the code that is supposed to reuse the cached statically initialized slices is broken and never generates the loads from cache. (if this worked you would see panics and memory corruptions)
Or the code that is creating theses stores into cache should not trigger in this case. (if this is spuriously triggering then you wouldn't have theses writes into globals)