I guess I have misunderstood something about the process of the allocation
and gc :) Maybe I need to learn from the gc theory first. BTW thanks for
your reply.
在2021年3月20日星期六 UTC+8 上午1:20:12<Ian Lance Taylor> 写道：
> On Thu, Mar 18, 2021 at 8:36 PM Paul Zhang <tianx...@gmail.com> wrote:
> >
> > Can I just understand that for the default case, when the compiler
> executes the mallocgc() for c.buf, it would use reflect to build the
> descriptor for the type of element? And if it allocates the both spaces in
> one function call, it wouldn't build the descriptor for the gc, and gc
> would find the descriptor later with more time, thus lead to worse
> performance? Thanks a lot!
>
> As Jan said, please post code as ordinary text or as a link to the Go
> playground or the Go sources. The colorized text on black is very
> difficult to read. Thanks.
>
> That said, I'm sorry, I don't really understand what you are asking.
>
> When the code you showed calls mallocgc, it passes the type descriptor
> for the channel element type. This is called "elem" in the code.
> This type descriptor was created by the compiler.
>
> If the runtime code allocated both the channel data structure and the
> buffer in a single memory allocation, it would need to have a type
> descriptor that combined the channel data structure with the element
> type. Not only that, this new type descriptor would change based on
> the argument passed to make. In the existing code, that is not
> necessary; when mallocgc is passed a type descriptor to allocate a
> size that is larger than the type, it understands that it is
> allocating an array. That wouldn't work for an allocation that shares
> the channel data structure with the channel buffer.
>
> I don't know what you mean when you say "gc would find the descriptor
> later with more time." The compiler would have to create the
> descriptor at compile time, so that the runtime code could use that
> type descriptor to allocate the memory. The gc can't find the
> descriptor later.
>
> Ian
>
>
> > Ian Lance Taylor <ia...@golang.org> 于2021年3月19日周五 上午2:50写道：
> >>
> >> On Thu, Mar 18, 2021 at 9:55 AM Paul Zhang <tianx...@gmail.com> wrote:
> >> >
> >> > I was reading the source code of makechan(), and these questions
> confused me. I would appreciate it if someone could help me.
> >> >
> >> > Q1. What does Elements do not contain pointers. mean? Does that means
> that the type of channel is not a pointer type (like chan int and chan
> *int)?
> >>
> >> It means that the element type of the channel is not a pointer and
> >> also does not contain any pointers. For example "struct { a, b int }"
> >> does not contain any pointers, but "struct { a int; b []byte }" does
> >> contain pointers.
> >>
> >>
> >> > Q2. Why does the allocation strategy of memory allocation differ? It
> seems like the buf and the hchan should be allocated into one piece of
> continuous memory, if the "elements contains pointers", so what's the
> point? The logically continuous memory might not physically continuous.
> >>
> >> The garbage collector has to always know exactly where pointers are
> >> stored in memory. We could in principle use contiguous allocation for
> >> the case where the element type contains pointers, but we would have
> >> to build a description that tells the garbage collector exactly where
> >> those pointers are. Those descriptions are built by the compiler (on
> >> tip, the code is in cmd/compile/internal/reflectdata/reflect.go), so
> >> the compiler would have to build a new descriptor for every channel
> >> type with an element type that contains pointers. And the descriptor
> >> would have to vary based on the channel size, so it would be based not
> >> just on the channel type but also on the argument passed to "make".
> >> Of course the argument passed to "make" can be a variable, so that
> >> adds another complication.
> >>
> >> So it's probably possible to use a contiguous buffer here, but it's
> >> not simple, and it's not the common case, and it's not clear that it
> >> would be worth it.
> >>
> >> 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/cdf05975-8000-4c01-9569-1cb337f17644n%40googlegroups.com.
