For this piece of code:
case elem.ptrdata == 0:
// Elements do not contain pointers.
// Allocate hchan and buf in one call.
c = (*hchan)(mallocgc(hchanSize+mem, nil, true))
c.buf = add(unsafe.Pointer(c), hchanSize)
default:
// Elements contain pointers.
c = new(hchan)
c.buf = mallocgc(mem, elem, true)
}
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!
Ian Lance Taylor <i...@golang.org> 于2021年3月19日周五 上午2:50写道：
> On Thu, Mar 18, 2021 at 9:55 AM Paul Zhang <tianxin8...@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/CANKef1sTdfZtxaoqeKZJSuOh5uRJxL90N0buuQuU-_YDdvCnxQ%40mail.gmail.com.
