Thanks Ian, I should have noted that I was asking about a specific version
of a specific Go compiler :)
That is very interesting info about the functions, maps and channels. I'll
have a bit more of a look around.
On Tuesday, 6 December 2016 18:50:42 UTC+1, Ian Lance Taylor wrote:
>
> On Tue, Dec 6, 2016 at 8:08 AM, Francis <francis...@gmail.com
> <javascript:>> wrote:
> > Today I was exploring some unexpected allocations that came from
> creating
> > empty interface{} values wrapping a string and an int. I spent some time
> > trying to clarify my understanding so I wouldn't be surprised in the
> future.
> >
> > I have consulted this excellent page
> http://research.swtch.com/interfaces
> > and written a small set of benchmarks. I am running Go 1.7
> >
> > My understanding of an interface is that it is made up of a pair of
> > pointers. The first is a pointer to an itable containing the concrete
> type
> > and a table of functions. The second pointer is to the data itself. We
> can
> > write this [*itable, *data].
> >
> > If we want to create an interface{} wrapping a string then we need to be
> > able to point to its itable and to the string itself. We assume the
> itable
> > already exists and we can point to it efficiently. However, although a
> > string behaves like a pointer it is a complex value containing [*data,
> > length] (I'll call this data structure a string-descriptor), so we can't
> > just use that as a pointer in our interface. We need to allocate the
> > string-descriptor, and the interface can then point to that location on
> the
> > heap.
> >
> > This is broadly true of most values in Go, as many pointer-like things
> are
> > actually complex values. But we would expect that an interface wrapping
> an
> > actual pointer wouldn't need to allocate at all.
> >
> > The benchmarks in the gist below seem to confirm that. However, there
> were a
> > mistakes and false paths in putting these benchmarks together so I would
> > appreciate it if someone could confirm that what I have described above
> is
> > true. And if it is not true, could you please clarify.
>
> What you describe above is true. I'll note that not all Go
> implementations implement interfaces in exactly the same way.
>
> Additional complexities are that the gc implementation treats
> functions, maps, and channels as pointer values, and does the same for
> single-element arrays and single-field structs with the single element
> or field is itself a pointer value (recursively defined). Also, note
> that zero-length values are always allocated to the same address, and
> as such do not take up any space in the heap.
>
> Ian
>
--
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.
