Who does the garbage collection work in go?

According to this specification, there is a mark-and-sweep garbage collection mechanism behind go. But who does it?

• Go code will compile to native binary, right? So there will not be a virtual machine like Java which it could rely on. So who does this dirty work for us? A cryptic thread? Or just a goroutine?

• Will the garbage collecting procedure stop-the-world like a full GC of Java? And could any one tell the difference of GC mechanisms between Java and Go? I could find rarely material on the net.

Many of your questions are answered here:

• https://stackoverflow.com/questions/7823725/what-kind-of-garbage-collection-does-go-use

For the rest:

> But who does it?

Native code runtime libraries provided by the Go implementation.

(I haven't looked at the implementation, but it is hard to imagine that you could implement a high-performance GC for Go "above the line" in the Go language.)

> Go code will compile to native binary, right?

Correct. The Go FAQ says so clearly.

> So there will not be a virtual machine like Java which it could rely on.

Correct. However, that makes no difference. In the Java case, the GC is also implemented by native code libraries provided by the Java runtime.

> So who does this dirty work for us? A cryptic thread? Or just a goroutine?

Well from Go 1.1 onwards, the GC is parallel so there must be some kind of multi-threading going on behind the scenes. Goroutines are a Go language concept, and it is hard to image that you would use them "below the line" in the native code GC implementation. (But I could be wrong ...)

But you also need to understand that goroutines also entail multiple threads under the hood. The FAQ says:

> "Why doesn't my multi-goroutine program use multiple CPUs?
>
> You must set the GOMAXPROCS shell environment variable or use the similarly-named function of the runtime package to allow the run-time support to utilize more than one OS thread."

See? Native / OS threads are involved under the hood.