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 48c744240800000000       MOVQ $0x0, 0x8(SP) 
>   0x458592 48c74424082a000000 MOVQ $0x2a, 0x8(SP) 
> testCases := [...][][]int{
>   0x45859b 48c705c28e060001000000 MOVQ $0x1, 0x68ec2(IP) 
>   0x4585a6 48c705bf8e060001000000 MOVQ $0x1, 0x68ebf(IP) 
>   0x4585b1 833d988d090000 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 e8e7cfffff CALL runtime.gcWriteBarrier(SB) 
>
> I have read the comments in slicelit 
> <https://github.com/golang/go/blob/fb6f38dda15d4155b500f6b3e1a311a951a22b69/src/cmd/compile/internal/walk/complit.go#L288>,
>   
> 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.

Reply via email to