[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object
Thanks for the relpy. I have opened an issue on github:
https://github.com/golang/go/issues/61730
On Thursday, 3 August 2023 at 17:49:25 UTC+8 Michael Knyszek wrote:
> That line (the full sentence is "The garbage collector now includes
> non-heap sources of garbage collector work (e.g., stack scanning) when
> determining how frequently to run.") is unrelated. It only refers to a
> change in accounting for what gets included in the GOGC calculation, not a
> change in what was marked and scanned by the GC.
>
> On Thursday, August 3, 2023 at 1:41:35 AM UTC-4 Qingwei Li wrote:
>
>> I notice that Go1.17.7 still allocates the array on heap by calling
>> newobject while Go1.18 allocates the array on stack. I also notice that in
>> the release note of Go1.18 that "The garbage collector now includes
>> non-heap sources of garbage collector work". Does the GC in 1.18 and
>> following versions of Go ignore some global memory area when marking?
>>
>> On Thursday, August 3, 2023 at 1:03:31 AM UTC+8 Jinbao Chen wrote:
>>
>>> I use go1.20.5 to compile the following code.
>>> package main
>>>
>>> func use(...interface{}) {
>>>
>>> }
>>>
>>> func main() {
>>> testCases := [...][][]int{
>>> {{42}},
>>> {{1, 2}},
>>> {{3, 4, 5}},
>>> {{}},
>>> {{1, 2}, {3, 4, 5}, {}, {7}},
>>> }
>>> for _, testCase := range testCases {
>>> use(testCase)
>>> }
>>> }
>>> In the generated SSA and assembly code, I notice that the Go compiler
>>> generates some instructions that store a stack pointer(point to the
>>> stack-allocated array) into a global slice header.
>>>
>>> Just like the assembly code below, the MOV instruction at 0x4585bf
>>> stores a stack pointer into a global object:
>>> 0x458589 48c7442408 MOVQ $0x0, 0x8(SP)
>>> 0x458592 48c74424082a00 MOVQ $0x2a, 0x8(SP)
>>> testCases := [...][][]int{
>>> 0x45859b 48c705c28e06000100 MOVQ $0x1, 0x68ec2(IP)
>>> 0x4585a6 48c705bf8e06000100 MOVQ $0x1, 0x68ebf(IP)
>>> 0x4585b1 833d988d09 CMPL $0x0, runtime.writeBarrier(SB)
>>> 0x4585b8 750e JNE 0x4585c8
>>> 0x4585ba 488d442408 LEAQ 0x8(SP), AX
>>> 0x4585bf 4889059a8e0600 MOVQ AX, 0x68e9a(IP)
>>> 0x4585c6 eb11 JMP 0x4585d9
>>> 0x4585c8 488d3d918e0600 LEAQ 0x68e91(IP), DI
>>> 0x4585cf 488d442408 LEAQ 0x8(SP), AX
>>> 0x4585d4 e8e7cf CALL runtime.gcWriteBarrier(SB)
>>>
>>> I have read the comments in slicelit
>>> ,
>>>
>>> but I didn't find any operations that can generate such stores. As far as I
>>> know, pointers to stack objects cannot be stored in global objects. So is
>>> this a compiler bug? Or the Go compiler does this on purpose to achieve
>>> some optimization I don't know yet?
>>>
>>> Thanks
>>>
>>
--
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/e7fc85da-8df8-43ee-b611-c57cbc142fa9n%40googlegroups.com.
[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object
That line (the full sentence is "The garbage collector now includes
non-heap sources of garbage collector work (e.g., stack scanning) when
determining how frequently to run.") is unrelated. It only refers to a
change in accounting for what gets included in the GOGC calculation, not a
change in what was marked and scanned by the GC.
On Thursday, August 3, 2023 at 1:41:35 AM UTC-4 Qingwei Li wrote:
> I notice that Go1.17.7 still allocates the array on heap by calling
> newobject while Go1.18 allocates the array on stack. I also notice that in
> the release note of Go1.18 that "The garbage collector now includes
> non-heap sources of garbage collector work". Does the GC in 1.18 and
> following versions of Go ignore some global memory area when marking?
>
> On Thursday, August 3, 2023 at 1:03:31 AM UTC+8 Jinbao Chen wrote:
>
>> I use go1.20.5 to compile the following code.
>> package main
>>
>> func use(...interface{}) {
>>
>> }
>>
>> func main() {
>> testCases := [...][][]int{
>> {{42}},
>> {{1, 2}},
>> {{3, 4, 5}},
>> {{}},
>> {{1, 2}, {3, 4, 5}, {}, {7}},
>> }
>> for _, testCase := range testCases {
>> use(testCase)
>> }
>> }
>> In the generated SSA and assembly code, I notice that the Go compiler
>> generates some instructions that store a stack pointer(point to the
>> stack-allocated array) into a global slice header.
>>
>> Just like the assembly code below, the MOV instruction at 0x4585bf stores
>> a stack pointer into a global object:
>> 0x458589 48c7442408 MOVQ $0x0, 0x8(SP)
>> 0x458592 48c74424082a00 MOVQ $0x2a, 0x8(SP)
>> testCases := [...][][]int{
>> 0x45859b 48c705c28e06000100 MOVQ $0x1, 0x68ec2(IP)
>> 0x4585a6 48c705bf8e06000100 MOVQ $0x1, 0x68ebf(IP)
>> 0x4585b1 833d988d09 CMPL $0x0, runtime.writeBarrier(SB)
>> 0x4585b8 750e JNE 0x4585c8
>> 0x4585ba 488d442408 LEAQ 0x8(SP), AX
>> 0x4585bf 4889059a8e0600 MOVQ AX, 0x68e9a(IP)
>> 0x4585c6 eb11 JMP 0x4585d9
>> 0x4585c8 488d3d918e0600 LEAQ 0x68e91(IP), DI
>> 0x4585cf 488d442408 LEAQ 0x8(SP), AX
>> 0x4585d4 e8e7cf CALL runtime.gcWriteBarrier(SB)
>>
>> I have read the comments in slicelit
>> ,
>>
>> but I didn't find any operations that can generate such stores. As far as I
>> know, pointers to stack objects cannot be stored in global objects. So is
>> this a compiler bug? Or the Go compiler does this on purpose to achieve
>> some optimization I don't know yet?
>>
>> Thanks
>>
>
--
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/74ee4bb3-da1b-4db9-a3df-e38d1df28b2dn%40googlegroups.com.
[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object
I notice that Go1.17.7 still allocates the array on heap by calling
newobject while Go1.18 allocates the array on stack. I also notice that in
the release note of Go1.18 that "The garbage collector now includes
non-heap sources of garbage collector work". Does the GC in 1.18 and
following versions of Go ignore some global memory area when marking?
On Thursday, August 3, 2023 at 1:03:31 AM UTC+8 Jinbao Chen wrote:
> I use go1.20.5 to compile the following code.
> package main
>
> func use(...interface{}) {
>
> }
>
> func main() {
> testCases := [...][][]int{
> {{42}},
> {{1, 2}},
> {{3, 4, 5}},
> {{}},
> {{1, 2}, {3, 4, 5}, {}, {7}},
> }
> for _, testCase := range testCases {
> use(testCase)
> }
> }
> In the generated SSA and assembly code, I notice that the Go compiler
> generates some instructions that store a stack pointer(point to the
> stack-allocated array) into a global slice header.
>
> Just like the assembly code below, the MOV instruction at 0x4585bf stores
> a stack pointer into a global object:
> 0x458589 48c7442408 MOVQ $0x0, 0x8(SP)
> 0x458592 48c74424082a00 MOVQ $0x2a, 0x8(SP)
> testCases := [...][][]int{
> 0x45859b 48c705c28e06000100 MOVQ $0x1, 0x68ec2(IP)
> 0x4585a6 48c705bf8e06000100 MOVQ $0x1, 0x68ebf(IP)
> 0x4585b1 833d988d09 CMPL $0x0, runtime.writeBarrier(SB)
> 0x4585b8 750e JNE 0x4585c8
> 0x4585ba 488d442408 LEAQ 0x8(SP), AX
> 0x4585bf 4889059a8e0600 MOVQ AX, 0x68e9a(IP)
> 0x4585c6 eb11 JMP 0x4585d9
> 0x4585c8 488d3d918e0600 LEAQ 0x68e91(IP), DI
> 0x4585cf 488d442408 LEAQ 0x8(SP), AX
> 0x4585d4 e8e7cf CALL runtime.gcWriteBarrier(SB)
>
> I have read the comments in slicelit
> ,
>
> but I didn't find any operations that can generate such stores. As far as I
> know, pointers to stack objects cannot be stored in global objects. So is
> this a compiler bug? Or the Go compiler does this on purpose to achieve
> some optimization I don't know yet?
>
> Thanks
>
--
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/67c81aa6-f6e0-40bf-a74b-273ffc7d02ben%40googlegroups.com.
[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object
Yes, that looks very, very wrong. It looks like this issue goes back to at
least 1.16.
If you can open an issue at https://github.com/golang/go/issues we can
investigate.
On Wednesday, August 2, 2023 at 10:03:31 AM UTC-7 Jinbao Chen wrote:
> I use go1.20.5 to compile the following code.
> package main
>
> func use(...interface{}) {
>
> }
>
> func main() {
> testCases := [...][][]int{
> {{42}},
> {{1, 2}},
> {{3, 4, 5}},
> {{}},
> {{1, 2}, {3, 4, 5}, {}, {7}},
> }
> for _, testCase := range testCases {
> use(testCase)
> }
> }
> In the generated SSA and assembly code, I notice that the Go compiler
> generates some instructions that store a stack pointer(point to the
> stack-allocated array) into a global slice header.
>
> Just like the assembly code below, the MOV instruction at 0x4585bf stores
> a stack pointer into a global object:
> 0x458589 48c7442408 MOVQ $0x0, 0x8(SP)
> 0x458592 48c74424082a00 MOVQ $0x2a, 0x8(SP)
> testCases := [...][][]int{
> 0x45859b 48c705c28e06000100 MOVQ $0x1, 0x68ec2(IP)
> 0x4585a6 48c705bf8e06000100 MOVQ $0x1, 0x68ebf(IP)
> 0x4585b1 833d988d09 CMPL $0x0, runtime.writeBarrier(SB)
> 0x4585b8 750e JNE 0x4585c8
> 0x4585ba 488d442408 LEAQ 0x8(SP), AX
> 0x4585bf 4889059a8e0600 MOVQ AX, 0x68e9a(IP)
> 0x4585c6 eb11 JMP 0x4585d9
> 0x4585c8 488d3d918e0600 LEAQ 0x68e91(IP), DI
> 0x4585cf 488d442408 LEAQ 0x8(SP), AX
> 0x4585d4 e8e7cf CALL runtime.gcWriteBarrier(SB)
>
> I have read the comments in slicelit
> ,
>
> but I didn't find any operations that can generate such stores. As far as I
> know, pointers to stack objects cannot be stored in global objects. So is
> this a compiler bug? Or the Go compiler does this on purpose to achieve
> some optimization I don't know yet?
>
> Thanks
>
--
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/f14aadcd-c0d8-4c61-abca-debe1ab5c208n%40googlegroups.com.
