Menu
My understanding is that executables of applications written in Go can stand alone without the need of Go installed in the machine.
Normally my understanding is that the GC (Garbage Collection) is handled by a VM. In this case, if the application is running independently without such a runtime how is GC handled?
A help on this and the documentation on the same would be nice.
783
It performs a blocking garbage collection of all generations. All objects, regardless of how long they have been in memory, are considered for collection; however, objects that are referenced in managed code are not collected. Use this method to force the system to try to reclaim the maximum amount of available memory.
Does Go have a runtime? Go does have an extensive library, called the runtime, that is part of every Go program. The runtime library implements garbage collection, concurrency, stack management, and other critical features of the Go language.
Generally speaking, in the presence of a garbage collector, it is never good practice to manually call the GC. A GC is organized around heuristic algorithms which work best when left to their own devices. Calling the GC manually often decreases performance.
my understanding is that the GC (Garbage Collection) is handled by a VM.
In the case of a typical VM supporting programming language featuring GC, (the compiled form of) a program written in that language is literally managed by the VM: the VM runs the code of the program and intervenes periodically to perform the GC tasks.
The crucial point is that each program running in such a VM may consider its VM as a part of its execution environment.
Another crucial point is that such VM represents the so-called runtime system for the so-called execution model of that programming language.
In this case, if the application is running independently without such a runtime how is GC handled?
Quite similar to the VM case.
Each Go program compiled by the stock toolchain (which can be downloaded from the official site
contains the Go runtime linked with the program itself.
Each compiled Go program is created in a way that when the program runs, the program's entry point executes the runtime first
which is responsible for initializing itself, then the program, and once this is finished, the execution is transferred to the program's main().
Among other things, the initialized Go runtime continuously runs one or more pieces of code of its own, which includes the goroutine scheduler and the GC (they are tightly coupled FWIW).
As you can see, the difference from the VM is that in that case the runtime is "external" to the running program while in the (typical) case of Go programs it's "along" the running program.
Nothing in the Go language specification mandates the precise way the runtime must be made available to the running program.
For instance, Go 1.11 can be compiled to WASM, and the runtime is partially provided by the linked-in code of the Go runtime and partially—by the WASM host (typically a browser).
As another example, GCC features a Go frontend, and contrary to the "stock" Go toolchan, and on those platforms where it's possible, GCC supports building Go in a way where their compiled forms dynamically link against a shared library containing most of the Go runtime code (and the code of the standard library). In this case, a compiled Go program does not contain the runtime code but it gets linked in when the program is being loaded and then it also works in-process with the program itself.
It's perfectly possible to implement an execution model for Go programs which would use a VM.
114
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
