On Sat, May 7, 2022 at 2:53 PM Axel Wagner <axel.wagner...@googlemail.com> wrote:
>> AFAICT, interior pointers do and must keep the entire allocation block >> alive, > > Is there any "official" documentation on the "must"? I don't think there is and I don't think it's necessary. I believe it's implied by the language semantics: The guarantees are primarily about what is kept, not about what is collected and when. It must be possible to dereference any non-nil pointer obtained "legally". From that follows, for example: if both the outer and inner pointers are reachable, the allocation block cannot be freed. If only the inner one is reachable, it's an implementation detail if the runtime keeps the outer alloc completely or reduces it to only the part reachable via the interior pointer. IIRC Go runtime used to keep things simple and just holds the whole allocation block. Might have changed meanwhile, >> but a sufficiently smart compiler is IMO free to ignore setting >> of the 23 value - or allocating the actual storage for .Y in F(), >> because no one can observe it - unless breaking the unsafe rules. > > > If internal pointers do, indeed, *must* keep the allocation alive, I can't > see how this would be allowed. After all, the code is unambiguous about > allocating a large object and returning a pointer into it - and if that > pointer must keep the entire object alive, surely a compiler can't just > decide to allocate a smaller one. The outer pointer does not leave F, initialization of the .Y field using a constant value has no side effects and the field is never read back anywhere in F. The only pointer that survives F's execution is the interior pointer so reducing the alloc to just a single int is not legally distinguishable from doing the "dead" allloc+init. > FWIW it seems at least currently, gc is not doing doing it: > https://godbolt.org/z/h74MchcT4 Yep, that seems to confirm the simple approach I mentioned above. It looks like a trivial optimization opportunity lost, but it's trivial only in very simple cases where I'd not expect big gains for average complexity code. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA40n-Vxivsu8gVA_NOGp0nENEj5CgqBJgEzxLuajsFUN5tyBQ%40mail.gmail.com.
