GCC 8 provides a complete implementation of the Go 1.10.1 user packages.
The garbage collector is now fully concurrent. As before, values stored on the stack are scanned conservatively, but value stored in the heap are scanned precisely.
Escape analysis is fully implemented and enabled by default in the Go frontend. This significantly reduces the number of heap allocations by allocating values on the stack instead.
I read this as "if it is on the stack and looks like a reference when you squint your eyes, then we treat it as a reference" compared to objects on the heap where the GC seems to know the exact location of all references.
Right that's the standard conservative garbage collection. However, new results show that it's significantly worse than a precise collector (reference pending).
I'd love to see that reference, as I've not yet seen an example where this was true in practicd, but know several examples where it is definitely false (e.g. we use a modification of the Julia GC which uses consevative stack scanning to allow interop with another system, and it seems to perform very well).
I think that only scanning the stack conservatively should not change much from a completely precise GC. The chances of misidentifying a potential reference to an enormous data structure that is collectable are pretty slim in a memory region as small as a typical stack.
Scanning the entire heap is different because of its generally much bigger size. It's far more likely then to see references where there are none.
