[jsnell]

The SBCL garbage collector doesn't work like described in the grandparent comment. It's precise for the heap, and only conservative for the registers and stacks.

I can't say for sure how the Go GC works, but I would assume it likewise isn't fully conservative. E.g. the "avoid struct types with both integer and pointer fields" advice would be pointless for a fully conservative GC, but does make sense if structs containing no pointers are allocated in a separate memory region that's not scanned for potential pointers.

[4ad]

I don't know anything about SBCL, but in Go the GC is used only for the heap, data allocated on the stack disappears as soon as the function returns, and registers have nothing to do with any of it.

[microtherion]

Both data on the stack and registers may potentially contain the sole live pointer to a particular heap object, so unless you only run GC from some sort of main event loop, it's generally necessary to treat the stack and registers as potential roots as well.

[jsnell]

Yes, but there are going to be pointers to heap objects in registers and on the stack.