How is Garbage Collection implemented in Go?
In Golang I saw that this language is compiled (and it is, the website itself says which architectures the compilers generate code for), and, to my surprise, it is Garbage Collected!
Garbage Collection is practically universal in the world of VM and interpreted languages.
And the implementation of these garbage collection algorithms is obvious: the interpreter/VM implements algorithms for collecting allocated memory; this is possible because the program execution is within the execution of another independent program that takes care of memory.
But in a compiled language, the program is "loose": it runs independently.
So without a wrapper runtime, how does Golang implement Garbage Collection?
Edit 1
Well, roughly speaking, what I understood from the answers was:
Go does not have a garbage collection runtime, but has a "companion" runtime: GC is implemented as a standard library of the language implementation. Every program written and compiled in Go runs independently, but next to it there is another runtime for memory.
2 answers
According to the language FAQ , Go uses a Parallel Collectormark-and-sweep.
The basic algorithm is the same one used in Java, but in parallel for better performance, consisting of scanning the "graph" of objects and marking the objects that are referenced in some way with a flag. After traversing all references, objects that are not marked can be removed from memory.
Consider a animation:
According to a SOEN Response version 1.3 of the Go language will implement a competing collector to improve on shorter processing breaks. Also according to this reference, the Go collector has the following characteristics:
- Non-generational: it does not use this approach that considers the "age" of the object.
- Non-compacting: does not move objects to rearrange memory crazy.
- Non-precise (no need): false positives may occur when "phlegging" an object, due to variant types that may or may not be pointers to objects.
- Stop-the-world: completely stops the execution of the program while it is running.
- Weak references: it does not support "weak" references, that is, they do not prevent the collector from cleaning the object.
To conclude, the fact of language being compiled does not actually influence the same having the ability to have or not a garbage collector of the instantiated objects. This idea that dynamic languages have the "loose" objects is just an impression, because underneath the cloths everything the JVM does is called to the C++ API to allocate and deallocate memory.
The point is the price to be paid for this type of facility. The developers of the Go language clearly state that it was a decision made based on the gain of productivity and the reduction of implementation complexity, especially with regard to programming that involves competition.
Programs written in the Go language, although compiled, will have the features required by the specification embedded in the generated executable.
The language will be compiled just like C, C++, Rust, etc, that is, directly to the machine code and not to an intermediate bytecode to be executed by a VM (which would provide GC for example). The difference with C and C++ is that this executable will have built in itself all the features so that not only GC works, but also the goroutines, channels etc.
Imagine programming C with GC, this is possible knew ? There are GC libraries for use in C language, in the end the same compiled binary as ever, no bytecodes, just a mere library. Go kind of does it to you under the cloths.
The same is true with Rust (specifically the case of GC, not yet, in the likely future).
As for the implementation / technology of the GC, I define the explanation for the documentation with a note about the use of escape analysis which is something interesting, in terms of performance, to have science even in a GC environment.