AFAIK when there's no pointer in elem (the channel's element's type), we
can cheat/optimize (call as you wish),
and allocate the channel's backing memory AND all it's elements' memory at
once, AS A BYTE ARRAY (nil is the second argument of mallocgc).
Then we can play unsafe tricks an treat it as proper channel and its buffer.
When there's pointer somewhere in the element's type, then - as the garbage
collector must know each and every pointer's placement -
we don't play tricks, and give mallocgc the proper type information, and
allocate the element buffer separate from the channel backing.
You'd have to repeat mallocgc's functionality to provide the gc with proper
information, just to save one allocation.
That'd be too much work for less gain.
tianx...@gmail.com a következőt írta (2021. március 19., péntek, 4:37:00
UTC+1):
> 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 <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/984487a7-2700-4fc1-a89f-feba29136af6n%40googlegroups.com.
