Re: [go-nuts] Why makechan distinguish elements do not contain pointers or contain pointers?

2019-01-28 Thread Ian Lance Taylor
On Sun, Jan 27, 2019 at 6:21 PM  wrote:
>
> It is in line 899 and line 914 of the malloc.go file.
>
> 899 spc := makeSpanClass(sizeclass, noscan)
> 914 s = largeAlloc(size, needzero, noscan)

Thanks, I wasn't aware of that.  Looks like we have spans that contain
only objects without pointers, and we record that in the span class.
This lets some other code skip those cases quickly.

The noscan flag is set for a span if the span contains only objects
without pointers.  But for a span that has objects that do contain
pointers, we still need to know where the pointers are.  Otherwise we
might mistake an integer for a pointer.  Knowing where those pointers
are requires knowing the type of the object.

Ian


> 在 2019年1月27日星期日 UTC+8下午1:55:29,Ian Lance Taylor写道:
>>
>> On Sat, Jan 26, 2019 at 6:50 PM  wrote:
>> >
>> > I am looking at go1.11.1.
>>
>> I don't see a "noscan" flag for mallocgc in 1.11.1.  There is a noscan
>> local variable, which is set of the type is passed as nil (the case I
>> mentioned earlier) or if the type has no pointers.
>>
>> > The memory allocation is still difficult to understand. What reference 
>> > materials can help me understand the context of this block?
>>
>> There is some information at golang.org/s/go14gc but I'm not sure it
>> quite covers what you are looking for.
>>
>> Ian
>>
>>
>> > 在 2019年1月27日星期日 UTC+8上午3:03:47,Ian Lance Taylor写道:
>> >>
>> >> On Sat, Jan 26, 2019 at 5:37 AM  wrote:
>> >> >
>> >> >  Why the garbage collector won't know how to find the pointers?
>> >> >  I looked at mallocgc and decided if the GC needs to scan this object 
>> >> > based on the noscan flag.
>> >>
>> >> What version of Go are you looking at?  There was a flagNoScan as late
>> >> as Go 1.6, but there is no such flag in current versions of Go.
>> >>
>> >> Ian
>> >>
>> >> > 在 2019年1月25日星期五 UTC+8下午10:58:44,Ian Lance Taylor写道:
>> >> >>
>> >> >> On Thu, Jan 24, 2019 at 11:58 PM  wrote:
>> >> >> >
>> >> >> > go 1.11.1 source code is below:
>> >> >> >
>> >> >> > Generally speaking, make chan just pay attention to the presence or 
>> >> >> > absence of buf.
>> >> >> >
>> >> >> > When I saw the source code of make chan,  I can understand case 1: 
>> >> >> > chan buf is 0, but can't understand case 2 & default.
>> >> >> >
>> >> >> > Who knows this principle?
>> >> >> >
>> >> >> > Thanks!
>> >> >> >
>> >> >> > var c *hchan
>> >> >> > switch {
>> >> >> > case size == 0 || elem.size == 0:
>> >> >> > // Queue or element size is zero.
>> >> >> > c = (*hchan)(mallocgc(hchanSize, nil, true))
>> >> >> > // Race detector uses this location for synchronization.
>> >> >> > c.buf = c.raceaddr()
>> >> >> > case elem.kind != 0:
>> >> >> > // Elements do not contain pointers.
>> >> >> > // Allocate hchan and buf in one call.
>> >> >> > c = (*hchan)(mallocgc(hchanSize+uintptr(size)*elem.size, 
>> >> >> > nil, true))
>> >> >> > c.buf = add(unsafe.Pointer(c), hchanSize)
>> >> >> > default:
>> >> >> > // Elements contain pointers.
>> >> >> > c = new(hchan)
>> >> >> > c.buf = mallocgc(uintptr(size)*elem.size, elem, true)
>> >> >> > }
>> >> >>
>> >> >>
>> >> >> First, let me say: please don't post screen shots.  They are much
>> >> >> harder to read than ordinary text.  I don't understand why anybody
>> >> >> ever posts screenshots of code, and I would be grateful for an
>> >> >> explanation.  Thanks.
>> >> >>
>> >> >> What is happening in that code is that if the channel has a non-zero
>> >> >> buffer size, we need to allocate space to hold the elements in the
>> >> >> buffer.  If the elements in the buffer do not contain any pointers, we
>> >> >> can optimize by allocating the channel structure (hchan) and the
>> >> >> buffer in a single memory allocation.  If the elements do contain
>> >> >> pointers, then that won't work, because the garbage collector won't
>> >> >> know how to find the pointers.  So in that case we allocate the hchan
>> >> >> struct and the buffer separately.  Note the second argument to
>> >> >> mallocgc, which is the type of the memory being allocated.  When there
>> >> >> are no pointers, we pass nil, which tells the garbage collector that
>> >> >> the allocation contains no pointers.  In the pointer case, we pass the
>> >> >> element type.
>> >> >>
>> >> >> 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...@googlegroups.com.
>> >> > For more options, visit https://groups.google.com/d/optout.
>> >
>> > --
>> > 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...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>

Re: [go-nuts] Why makechan distinguish elements do not contain pointers or contain pointers?

2019-01-27 Thread mountainfpf
It is in line 899 and line 914 of the malloc.go file.

899 spc := makeSpanClass(sizeclass, noscan)
914 s = largeAlloc(size, needzero, noscan)

在 2019年1月27日星期日 UTC+8下午1:55:29,Ian Lance Taylor写道:
>
> On Sat, Jan 26, 2019 at 6:50 PM > wrote: 
> > 
> > I am looking at go1.11.1. 
>
> I don't see a "noscan" flag for mallocgc in 1.11.1.  There is a noscan 
> local variable, which is set of the type is passed as nil (the case I 
> mentioned earlier) or if the type has no pointers. 
>
> > The memory allocation is still difficult to understand. What reference 
> materials can help me understand the context of this block? 
>
> There is some information at golang.org/s/go14gc but I'm not sure it 
> quite covers what you are looking for. 
>
> Ian 
>
>
> > 在 2019年1月27日星期日 UTC+8上午3:03:47,Ian Lance Taylor写道: 
> >> 
> >> On Sat, Jan 26, 2019 at 5:37 AM  wrote: 
> >> > 
> >> >  Why the garbage collector won't know how to find the pointers? 
> >> >  I looked at mallocgc and decided if the GC needs to scan this object 
> based on the noscan flag. 
> >> 
> >> What version of Go are you looking at?  There was a flagNoScan as late 
> >> as Go 1.6, but there is no such flag in current versions of Go. 
> >> 
> >> Ian 
> >> 
> >> > 在 2019年1月25日星期五 UTC+8下午10:58:44,Ian Lance Taylor写道: 
> >> >> 
> >> >> On Thu, Jan 24, 2019 at 11:58 PM  wrote: 
> >> >> > 
> >> >> > go 1.11.1 source code is below: 
> >> >> > 
> >> >> > Generally speaking, make chan just pay attention to the presence 
> or absence of buf. 
> >> >> > 
> >> >> > When I saw the source code of make chan,  I can understand case 1: 
> chan buf is 0, but can't understand case 2 & default. 
> >> >> > 
> >> >> > Who knows this principle? 
> >> >> > 
> >> >> > Thanks! 
> >> >> > 
> >> >> > var c *hchan 
> >> >> > switch { 
> >> >> > case size == 0 || elem.size == 0: 
> >> >> > // Queue or element size is zero. 
> >> >> > c = (*hchan)(mallocgc(hchanSize, nil, true)) 
> >> >> > // Race detector uses this location for synchronization. 
> >> >> > c.buf = c.raceaddr() 
> >> >> > case elem.kind != 0: 
> >> >> > // Elements do not contain pointers. 
> >> >> > // Allocate hchan and buf in one call. 
> >> >> > c = (*hchan)(mallocgc(hchanSize+uintptr(size)*elem.size, 
> nil, true)) 
> >> >> > c.buf = add(unsafe.Pointer(c), hchanSize) 
> >> >> > default: 
> >> >> > // Elements contain pointers. 
> >> >> > c = new(hchan) 
> >> >> > c.buf = mallocgc(uintptr(size)*elem.size, elem, true) 
> >> >> > } 
> >> >> 
> >> >> 
> >> >> First, let me say: please don't post screen shots.  They are much 
> >> >> harder to read than ordinary text.  I don't understand why anybody 
> >> >> ever posts screenshots of code, and I would be grateful for an 
> >> >> explanation.  Thanks. 
> >> >> 
> >> >> What is happening in that code is that if the channel has a non-zero 
> >> >> buffer size, we need to allocate space to hold the elements in the 
> >> >> buffer.  If the elements in the buffer do not contain any pointers, 
> we 
> >> >> can optimize by allocating the channel structure (hchan) and the 
> >> >> buffer in a single memory allocation.  If the elements do contain 
> >> >> pointers, then that won't work, because the garbage collector won't 
> >> >> know how to find the pointers.  So in that case we allocate the 
> hchan 
> >> >> struct and the buffer separately.  Note the second argument to 
> >> >> mallocgc, which is the type of the memory being allocated.  When 
> there 
> >> >> are no pointers, we pass nil, which tells the garbage collector that 
> >> >> the allocation contains no pointers.  In the pointer case, we pass 
> the 
> >> >> element type. 
> >> >> 
> >> >> 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...@googlegroups.com. 
> >> > For more options, visit https://groups.google.com/d/optout. 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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.


Re: [go-nuts] Why makechan distinguish elements do not contain pointers or contain pointers?

2019-01-26 Thread Ian Lance Taylor
On Sat, Jan 26, 2019 at 6:50 PM  wrote:
>
> I am looking at go1.11.1.

I don't see a "noscan" flag for mallocgc in 1.11.1.  There is a noscan
local variable, which is set of the type is passed as nil (the case I
mentioned earlier) or if the type has no pointers.

> The memory allocation is still difficult to understand. What reference 
> materials can help me understand the context of this block?

There is some information at golang.org/s/go14gc but I'm not sure it
quite covers what you are looking for.

Ian


> 在 2019年1月27日星期日 UTC+8上午3:03:47,Ian Lance Taylor写道:
>>
>> On Sat, Jan 26, 2019 at 5:37 AM  wrote:
>> >
>> >  Why the garbage collector won't know how to find the pointers?
>> >  I looked at mallocgc and decided if the GC needs to scan this object 
>> > based on the noscan flag.
>>
>> What version of Go are you looking at?  There was a flagNoScan as late
>> as Go 1.6, but there is no such flag in current versions of Go.
>>
>> Ian
>>
>> > 在 2019年1月25日星期五 UTC+8下午10:58:44,Ian Lance Taylor写道:
>> >>
>> >> On Thu, Jan 24, 2019 at 11:58 PM  wrote:
>> >> >
>> >> > go 1.11.1 source code is below:
>> >> >
>> >> > Generally speaking, make chan just pay attention to the presence or 
>> >> > absence of buf.
>> >> >
>> >> > When I saw the source code of make chan,  I can understand case 1: chan 
>> >> > buf is 0, but can't understand case 2 & default.
>> >> >
>> >> > Who knows this principle?
>> >> >
>> >> > Thanks!
>> >> >
>> >> > var c *hchan
>> >> > switch {
>> >> > case size == 0 || elem.size == 0:
>> >> > // Queue or element size is zero.
>> >> > c = (*hchan)(mallocgc(hchanSize, nil, true))
>> >> > // Race detector uses this location for synchronization.
>> >> > c.buf = c.raceaddr()
>> >> > case elem.kind != 0:
>> >> > // Elements do not contain pointers.
>> >> > // Allocate hchan and buf in one call.
>> >> > c = (*hchan)(mallocgc(hchanSize+uintptr(size)*elem.size, nil, 
>> >> > true))
>> >> > c.buf = add(unsafe.Pointer(c), hchanSize)
>> >> > default:
>> >> > // Elements contain pointers.
>> >> > c = new(hchan)
>> >> > c.buf = mallocgc(uintptr(size)*elem.size, elem, true)
>> >> > }
>> >>
>> >>
>> >> First, let me say: please don't post screen shots.  They are much
>> >> harder to read than ordinary text.  I don't understand why anybody
>> >> ever posts screenshots of code, and I would be grateful for an
>> >> explanation.  Thanks.
>> >>
>> >> What is happening in that code is that if the channel has a non-zero
>> >> buffer size, we need to allocate space to hold the elements in the
>> >> buffer.  If the elements in the buffer do not contain any pointers, we
>> >> can optimize by allocating the channel structure (hchan) and the
>> >> buffer in a single memory allocation.  If the elements do contain
>> >> pointers, then that won't work, because the garbage collector won't
>> >> know how to find the pointers.  So in that case we allocate the hchan
>> >> struct and the buffer separately.  Note the second argument to
>> >> mallocgc, which is the type of the memory being allocated.  When there
>> >> are no pointers, we pass nil, which tells the garbage collector that
>> >> the allocation contains no pointers.  In the pointer case, we pass the
>> >> element type.
>> >>
>> >> 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...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.

-- 
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.


Re: [go-nuts] Why makechan distinguish elements do not contain pointers or contain pointers?

2019-01-26 Thread mountainfpf
I am looking at go1.11.1.
The memory allocation is still difficult to understand. What reference 
materials can help me understand the context of this block?

在 2019年1月27日星期日 UTC+8上午3:03:47,Ian Lance Taylor写道:
>
> On Sat, Jan 26, 2019 at 5:37 AM > wrote: 
> > 
> >  Why the garbage collector won't know how to find the pointers? 
> >  I looked at mallocgc and decided if the GC needs to scan this object 
> based on the noscan flag. 
>
> What version of Go are you looking at?  There was a flagNoScan as late 
> as Go 1.6, but there is no such flag in current versions of Go. 
>
> Ian 
>
> > 在 2019年1月25日星期五 UTC+8下午10:58:44,Ian Lance Taylor写道: 
> >> 
> >> On Thu, Jan 24, 2019 at 11:58 PM  wrote: 
> >> > 
> >> > go 1.11.1 source code is below: 
> >> > 
> >> > Generally speaking, make chan just pay attention to the presence or 
> absence of buf. 
> >> > 
> >> > When I saw the source code of make chan,  I can understand case 1: 
> chan buf is 0, but can't understand case 2 & default. 
> >> > 
> >> > Who knows this principle? 
> >> > 
> >> > Thanks! 
> >> > 
> >> > var c *hchan 
> >> > switch { 
> >> > case size == 0 || elem.size == 0: 
> >> > // Queue or element size is zero. 
> >> > c = (*hchan)(mallocgc(hchanSize, nil, true)) 
> >> > // Race detector uses this location for synchronization. 
> >> > c.buf = c.raceaddr() 
> >> > case elem.kind != 0: 
> >> > // Elements do not contain pointers. 
> >> > // Allocate hchan and buf in one call. 
> >> > c = (*hchan)(mallocgc(hchanSize+uintptr(size)*elem.size, nil, 
> true)) 
> >> > c.buf = add(unsafe.Pointer(c), hchanSize) 
> >> > default: 
> >> > // Elements contain pointers. 
> >> > c = new(hchan) 
> >> > c.buf = mallocgc(uintptr(size)*elem.size, elem, true) 
> >> > } 
> >> 
> >> 
> >> First, let me say: please don't post screen shots.  They are much 
> >> harder to read than ordinary text.  I don't understand why anybody 
> >> ever posts screenshots of code, and I would be grateful for an 
> >> explanation.  Thanks. 
> >> 
> >> What is happening in that code is that if the channel has a non-zero 
> >> buffer size, we need to allocate space to hold the elements in the 
> >> buffer.  If the elements in the buffer do not contain any pointers, we 
> >> can optimize by allocating the channel structure (hchan) and the 
> >> buffer in a single memory allocation.  If the elements do contain 
> >> pointers, then that won't work, because the garbage collector won't 
> >> know how to find the pointers.  So in that case we allocate the hchan 
> >> struct and the buffer separately.  Note the second argument to 
> >> mallocgc, which is the type of the memory being allocated.  When there 
> >> are no pointers, we pass nil, which tells the garbage collector that 
> >> the allocation contains no pointers.  In the pointer case, we pass the 
> >> element type. 
> >> 
> >> 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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.


Re: [go-nuts] Why makechan distinguish elements do not contain pointers or contain pointers?

2019-01-26 Thread Ian Lance Taylor
On Sat, Jan 26, 2019 at 5:37 AM  wrote:
>
>  Why the garbage collector won't know how to find the pointers?
>  I looked at mallocgc and decided if the GC needs to scan this object based 
> on the noscan flag.

What version of Go are you looking at?  There was a flagNoScan as late
as Go 1.6, but there is no such flag in current versions of Go.

Ian

> 在 2019年1月25日星期五 UTC+8下午10:58:44,Ian Lance Taylor写道:
>>
>> On Thu, Jan 24, 2019 at 11:58 PM  wrote:
>> >
>> > go 1.11.1 source code is below:
>> >
>> > Generally speaking, make chan just pay attention to the presence or 
>> > absence of buf.
>> >
>> > When I saw the source code of make chan,  I can understand case 1: chan 
>> > buf is 0, but can't understand case 2 & default.
>> >
>> > Who knows this principle?
>> >
>> > Thanks!
>> >
>> > var c *hchan
>> > switch {
>> > case size == 0 || elem.size == 0:
>> > // Queue or element size is zero.
>> > c = (*hchan)(mallocgc(hchanSize, nil, true))
>> > // Race detector uses this location for synchronization.
>> > c.buf = c.raceaddr()
>> > case elem.kind != 0:
>> > // Elements do not contain pointers.
>> > // Allocate hchan and buf in one call.
>> > c = (*hchan)(mallocgc(hchanSize+uintptr(size)*elem.size, nil, 
>> > true))
>> > c.buf = add(unsafe.Pointer(c), hchanSize)
>> > default:
>> > // Elements contain pointers.
>> > c = new(hchan)
>> > c.buf = mallocgc(uintptr(size)*elem.size, elem, true)
>> > }
>>
>>
>> First, let me say: please don't post screen shots.  They are much
>> harder to read than ordinary text.  I don't understand why anybody
>> ever posts screenshots of code, and I would be grateful for an
>> explanation.  Thanks.
>>
>> What is happening in that code is that if the channel has a non-zero
>> buffer size, we need to allocate space to hold the elements in the
>> buffer.  If the elements in the buffer do not contain any pointers, we
>> can optimize by allocating the channel structure (hchan) and the
>> buffer in a single memory allocation.  If the elements do contain
>> pointers, then that won't work, because the garbage collector won't
>> know how to find the pointers.  So in that case we allocate the hchan
>> struct and the buffer separately.  Note the second argument to
>> mallocgc, which is the type of the memory being allocated.  When there
>> are no pointers, we pass nil, which tells the garbage collector that
>> the allocation contains no pointers.  In the pointer case, we pass the
>> element type.
>>
>> 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.

-- 
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.


Re: [go-nuts] Why makechan distinguish elements do not contain pointers or contain pointers?

2019-01-26 Thread mountainfpf
 Why the garbage collector won't know how to find the pointers?
 I looked at mallocgc and decided if the GC needs to scan this object based 
on the noscan flag.

在 2019年1月25日星期五 UTC+8下午10:58:44,Ian Lance Taylor写道:
>
> On Thu, Jan 24, 2019 at 11:58 PM > 
> wrote: 
> > 
> > go 1.11.1 source code is below: 
> > 
> > Generally speaking, make chan just pay attention to the presence or 
> absence of buf. 
> > 
> > When I saw the source code of make chan,  I can understand case 1: chan 
> buf is 0, but can't understand case 2 & default. 
> > 
> > Who knows this principle? 
> > 
> > Thanks! 
> > 
> > var c *hchan 
> > switch { 
> > case size == 0 || elem.size == 0: 
> > // Queue or element size is zero. 
> > c = (*hchan)(mallocgc(hchanSize, nil, true)) 
> > // Race detector uses this location for synchronization. 
> > c.buf = c.raceaddr() 
> > case elem.kind != 0: 
> > // Elements do not contain pointers. 
> > // Allocate hchan and buf in one call. 
> > c = (*hchan)(mallocgc(hchanSize+uintptr(size)*elem.size, nil, 
> true)) 
> > c.buf = add(unsafe.Pointer(c), hchanSize) 
> > default: 
> > // Elements contain pointers. 
> > c = new(hchan) 
> > c.buf = mallocgc(uintptr(size)*elem.size, elem, true) 
> > } 
>
>
> First, let me say: please don't post screen shots.  They are much 
> harder to read than ordinary text.  I don't understand why anybody 
> ever posts screenshots of code, and I would be grateful for an 
> explanation.  Thanks. 
>
> What is happening in that code is that if the channel has a non-zero 
> buffer size, we need to allocate space to hold the elements in the 
> buffer.  If the elements in the buffer do not contain any pointers, we 
> can optimize by allocating the channel structure (hchan) and the 
> buffer in a single memory allocation.  If the elements do contain 
> pointers, then that won't work, because the garbage collector won't 
> know how to find the pointers.  So in that case we allocate the hchan 
> struct and the buffer separately.  Note the second argument to 
> mallocgc, which is the type of the memory being allocated.  When there 
> are no pointers, we pass nil, which tells the garbage collector that 
> the allocation contains no pointers.  In the pointer case, we pass the 
> element type. 
>
> 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.


Re: [go-nuts] Why makechan distinguish elements do not contain pointers or contain pointers?

2019-01-25 Thread Ian Lance Taylor
On Thu, Jan 24, 2019 at 11:58 PM  wrote:
>
> go 1.11.1 source code is below:
>
> Generally speaking, make chan just pay attention to the presence or absence 
> of buf.
>
> When I saw the source code of make chan,  I can understand case 1: chan buf 
> is 0, but can't understand case 2 & default.
>
> Who knows this principle?
>
> Thanks!
>
> var c *hchan
> switch {
> case size == 0 || elem.size == 0:
> // Queue or element size is zero.
> c = (*hchan)(mallocgc(hchanSize, nil, true))
> // Race detector uses this location for synchronization.
> c.buf = c.raceaddr()
> case elem.kind != 0:
> // Elements do not contain pointers.
> // Allocate hchan and buf in one call.
> c = (*hchan)(mallocgc(hchanSize+uintptr(size)*elem.size, nil, true))
> c.buf = add(unsafe.Pointer(c), hchanSize)
> default:
> // Elements contain pointers.
> c = new(hchan)
> c.buf = mallocgc(uintptr(size)*elem.size, elem, true)
> }


First, let me say: please don't post screen shots.  They are much
harder to read than ordinary text.  I don't understand why anybody
ever posts screenshots of code, and I would be grateful for an
explanation.  Thanks.

What is happening in that code is that if the channel has a non-zero
buffer size, we need to allocate space to hold the elements in the
buffer.  If the elements in the buffer do not contain any pointers, we
can optimize by allocating the channel structure (hchan) and the
buffer in a single memory allocation.  If the elements do contain
pointers, then that won't work, because the garbage collector won't
know how to find the pointers.  So in that case we allocate the hchan
struct and the buffer separately.  Note the second argument to
mallocgc, which is the type of the memory being allocated.  When there
are no pointers, we pass nil, which tells the garbage collector that
the allocation contains no pointers.  In the pointer case, we pass the
element type.

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.


[go-nuts] Why makechan distinguish elements do not contain pointers or contain pointers?

2019-01-24 Thread mountainfpf
go 1.11.1 source code is below:

Generally speaking, make chan just pay attention to the presence or absence 
of buf.

When I saw the source code of make chan,  I can understand case 1: chan buf 
is 0, but can't understand case 2 & default.

Who knows this principle?

Thanks!

var c *hchan
switch {
case size == 0 || elem.size == 0:
// Queue or element size is zero.
c = (*hchan)(mallocgc(hchanSize, nil, true))
// Race detector uses this location for synchronization.
c.buf = c.raceaddr()
case elem.kind != 0:
// Elements do not contain pointers.
// Allocate hchan and buf in one call.
c = (*hchan)(mallocgc(hchanSize+uintptr(size)*elem.size, nil, true))
c.buf = add(unsafe.Pointer(c), hchanSize)
default:
// Elements contain pointers.
c = new(hchan)
c.buf = mallocgc(uintptr(size)*elem.size, elem, true)
}

-- 
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.