How is Garbage Collection implemented in Go?

15

In Golang I saw that this language is compiled (and that's right, the website itself tells which architectures compilers generate code for), and, to my surprise, it's Garbage Collected!

Garbage Collection is virtually universal in the world of interpreted and interpreted languages.

And the implementation of these garbage collection algorithms is obvious: The interpreter / VM implements algorithms for allocating 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 runtime wrapper, how does Golang implement Garbage Collection?

Edit 1

Well, roughly speaking, what I understood from the answers was:

Go does not have a runtime for garbage collection, but has a "companion" runtime: GC is implemented as a standard library of language implementation. Every program written and compiled in Go runs independently, but next to it is another runtime for memory.

    
asked by anonymous 19.04.2014 / 01:42

2 answers

8

According to the Language FAQ , Go uses a parallel collector mark-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 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 the animation:

Accordingtoa SOEN response version 1.3 of Go's language will implement a competing collector to improve on smaller processing breaks. Also according to this reference, the Go collector has the following characteristics:

  • Non-generational : Does not use this approach that considers the "age" of the object.
  • Non-compelling : does not move objects to rearrange allocated memory.
  • Non-precise : False positives may occur when you "thumb" an object, due to variant types that may or may not be pointers to objects.
  • Stop-the-world : Completely stops running the program as it runs.
  • Weak references : does not support "weak" references, that is, they do not prevent the collector from cleaning the object.

To conclude, the fact that the language is compiled does not in fact influence whether it has the ability to have a garbage collector for the instantiated objects. This idea of dynamic languages has the objects "loose" is just an impression, because underneath the cloth everything that the JVM does is called to the C ++ API to allocate and deallocate the memory.

The point is the price to be paid for this type of facility. Developers of the Go language clearly state that it was a decision made based on productivity gains and reduced implementation complexity, especially with regard to programming involving competition.

    
28.04.2014 / 23:24
4
Programs written in Go language, although compiled, will have the features required by the embedded specification in the generated executable.

The language will be compiled just like C, C ++, Rust, etc., ie directly to the machine code and not to an intermediate bytecode to be run by a VM (which would provide GC for example). The difference with C and C ++ is that this executable will have built-in all the features so that not only GC works, but also the goroutines, the channels etc.

Imagine programming C with GC, is this possible ? There are GC libraries for use in C language, in the end the same binary compiled as ever, no bytecodes, just a mere library. Go kind of does it for you underneath the rags.

The same goes for Rust (specifically the GC case, not yet, in the likely future).

Regarding the implementation / technology of the GC, I explain the documentation with a note on the use of escape analysis which is something interesting, in terms of performance, to be aware of even in a GC environment.

    
29.04.2014 / 02:28