Go’s runtime vs virtual machine

[Pablo]

The Go documentation provides some explanation about the difference between Go’s runtime and a virtual machine here:

https://golang.org/doc/faq#runtime

Does anyone can recommend a good place to learn more about this? I’d like to better understand how Go’s garbage collector, goroutine scheduling and stack management are handled by the runtime and how it is different from a virtual machine.

Thanks,

Pablo

[thwd]

A virtual machine has its own instruction set. Go compiles to machine code for a given target (which could be a virtual machine).

[jake...@gmail.com]

There are a lot of differences, and for the answer to be complete, you would need to specify which language you wanted to compare it to. But on a really simple level, thwd's answer is more or less correct. A VM language is usually compiled into an instruction set for that VM. The VM then provides a lot of "special sauce." Go is (usually) compiled directly into machine code to be executed directly on the target system.

One consequence of this is that the executable can be run without having any other software installed on the machine. It also  means that the code for the stuff you inquired about such as the garbage collector, goroutine scheduling and stack management, is all present in the single executable compiled by go.

As for learning more, it depends somewhat on what your experience level is, and why you want to know. If you are relatively new to programming, I would recommend just using go for a while, without worrying too much about the "magic."  If you have a strong background already, you could start learning about the stuff you mentioned. Garbage collection would be an interesting place to start. I don't know of any one resource, but there are a number of interesting videos (gophercon, ect) by principal architects on the subject. Keep in mind that all these things are constantly evolving, so any information you get may not apply to the latest version of the language.

Good luck.

[Pablo Rozas Larraondo]

Thanks for the answers. I asked this question because I'm preparing some tutorials to explain Go to students and I'm thinking about potential questions and discussions.

If I understand it correctly we could say then that Go's runtime has things in common with a VM's runtime (I'm thinking mostly in Java's) such as GC, goroutine (thread) scheduling, etc. However, Go's runtime cannot be considered a VM because it does not compile code to an intermediate language, it executes compiled native code instead.

Cheers,

Pablo

[Christopher Nielsen]

Hi Pablo,

Yes, that sounds like a reasonable differentiation for students. Of course, it is more complex than that, but it's a good first principles introduction.

Cheers,

Chris

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Volker Dobler]

On Wednesday, 5 September 2018 01:57:33 UTC+2, Pablo Rozas Larraondo wrote:

If I understand it correctly we could say then that Go's runtime has things in common with a VM's runtime (I'm thinking mostly in Java's) such as GC, goroutine (thread) scheduling, etc. However, Go's runtime cannot be considered a VM because it does not compile code to an intermediate language, it executes compiled native code instead.

But then one could argue that Go's runtime has things in

common with the operating system such as memory

management and goroutine/thread scheduling, etc.

I probably would explain what the runtime does and why it

does these things. Then explain that these things are

important and that lots of other things provide the same

services, e.g. the kernel or a virtual machine because these

are common hard problems. Lions and and jellyfish both

hunt because they need food but explaining lions in terms

of jellyfish (or the other way around) is probably not helpful

(especially as most students do not have deep understanding

of a lion's or Java VM's internals.)

V.

 

[Michael Jones]

I might tell students step by step:

machine code is understood and executed by a machine.

-> the intel instruction to increment a register is decoded and executed by the CPU's hardware.

virtual code is understood and executed by a program that pretends to be some virtual CPU.

-> a Java VM might run on an intel CPU and understand and execute Java virtual machine instructions.

-> a Java VM might run on an intel VM that actually runs on an ARM CPU...

-> ...like a Russian matryoshka doll, there can be any number of outer VMs before the innermost real CPU.

operating systems provide protection, resource allocation, and services.

most languages offer programs at least some operating system like services via a runtime service layer

-> in C, this was initially "crt0" the thin c runtime

-> in Go, the service layer is richer, offering thread management and goroutine multiplexing, garbage collection, and more.

the Go runtime is written in Go mostly and uses C or assembler to connect to the host operating system.

the Go runtime is linked with the developer's Go code, and the two of them are constitute the output of go build or go install

--

Michael T. Jones
michae...@gmail.com

[andrey mirtchovski]

> most languages offer programs at least some operating system like services via a runtime service layer
> -> in C, this was initially "crt0" the thin c runtime
> -> in Go, the service layer is richer, offering thread management and goroutine multiplexing, garbage collection, and more.
>
> the Go runtime is written in Go mostly and uses C or assembler to connect to the host operating system.
> the Go runtime is linked with the developer's Go code, and the two of them are constitute the output of go build or go install

I would add that, unlike VMs simulating CPUs, there can't be a
matryoshka-doll infinity of Go runtimes resting on other Go runtimes.
There is just one, which interfaces with the underlying OS directly.

[Christopher Nielsen]

Michael,

I agree that this is probably more useful in the long-term. Thank you for adding the detail.

Cheers,

Chris

[K Davidson]

\0, Pablo,

IMHO although the runtime and VM both provide facilities such as garbage collection, scheduling ect they are not alike at all. Actually that is the ONLY way they are alike. VM run compiled bytcode like others stated, but the VM is a whole program on its own, which is run, and handled by the os like a compiled-to-machine code program would be, and then that (VM) program reads and runs the bytecode compiled program.

Whereas instead of being a seperate program in it's own right, Go's runtime is actually just a set of libraries that are compiled into every Go binary. Just like the std libraries that you import into your program (ie "fmt") they are compiled and linked along with user code into a single program. In fact, you can also import these libraries into your code manually and play with it; with a VM you don't have the same ability. (*some VMs can be 'tuned', but only from knobs that are specifically givin to you, not arbitrarily)

The end result is that you get all the facilities for managing memory, goroutine schedualing, ect that you want from a virtual machine, but interwoven into your code, which as a whole is then compiled down to raw machine code.

If you want to learn more about how this is all implemented, I find that the go source is extremely approchable, and even a beginner should be able to get some idea about what the code is doing. ("$GOROOT/src/runtime is a good starting place)

[K Davidson]

Please give my seemingly redundant post. I got stiffled by the moderation process, and by the time my post was approved, others had said pretty much everything I had.

[Michael Jones]

These are all great! If Pablo gets these points across to students, they will be well-informed.

There is an interesting parallel to human languages. When I was a boy my father told me "you don't know a word if you can't define it." Sometimes people are comfortable with words they understand generally but could not define precisely; that's a false comfort. This thread gives all of us the chance to think how to define terms, how to be clear so as to avoid confusion on the part of others. It is a rewarding exercise for ourselves too.

On Wed, Sep 5, 2018 at 7:55 AM K Davidson <kde...@gmail.com> wrote:

Please give my seemingly redundant post. I got stiffled by the moderation process, and by the time my post was approved, others had said pretty much everything I had.

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pablo Rozas Larraondo]

This is awesome, thank you all very much for the background information and great examples that you've provided. I think it is quite clear now what the difference is between these two runtimes.

Cheers,

Pablo