proposal: design of a bytecode interpreter for Go

[sbinet]

Let's do actual work on https://docs.google.com/document/d/1Hvxf6NMPaCUd-1iqm_968SuHN1Vf8dLZQyHjvPyVE0Q/edit

There are currently a few Go interpreters on the market:

• llgoi, a JIT-enabled interpreter built on top of LLVM and llgo
• ssainterp, an interpreter built on top of golang.org/x/tools/go/ssa
• sbinet/go-eval, a package salvaged from pre-Go1
• various REPLs that compile on the fly Go statements and execute them,
• etc...

The high-level view of this proposal is to describe a naive interactive interpreter for Go, loosely based on the design and implementation of Dis [1], [2], the virtual machine of the Inferno OS.
Knowing Go lineage, then, why not?

Dis is a register-based interpreter.
It's not alone in the register-based space: one of the most known register-based VM is Lua. See: here and there for inspirations.

Alternatively, we could base the design on a stack-based VM such as CPython's.
See here and there for some inspirations.
Stack-based VMs are somewhat easier to implement but literature would seem to indicate register-based VMs are more performance friendly.

Working at the bytecode level, with program counters, instructions and frames, should allow us to reuse a fair amount of the cmd/compile infrastructure of the official Go compiler, and to also provide a non-interactive interpreter (i.e.: interpreting whole programs.)

PS: design proposal is here: #2
PPS: additional reddit comments at https://www.reddit.com/r/golang/comments/4zu6bc/gointerpreter_design_proposal_of_a_vm_for_go

other VMs:

• https://github.com/db47h/ngaro/tree/master/vm
• https://github.com/dop251/goja
• https://github.com/milochristiansen/lua

[elliott5]

Thank you Seb, for starting this conversation again, especially in so structured a way. Re-reading the interp-ideas document from 10 months ago, I still think the ideas hold good.

We certainly need a VM to target and, to be self-hosting on all Go platforms, that target VM needs a pure Go implementation.

The simplest route has us inventing a Go-specific VM that exactly implements what is required for Go, and then writing two components a Go->VMbitcode compiler and a VMbitcode interpreter. Aside from the VMbitcode serialization/deserialization part, this is essentially what ssainterp already does. For a list of the Go-specific instructions see the table at: https://godoc.org/golang.org/x/tools/go/ssa

As we would control the format of our own VM, extending it in whatever ways were required to enable a REPL user interface would be relatively straightforward.

But there are two strong attractions to using an existing VM:

• Reusing the existing really fast implementations of that VM, maybe even for targets that Go does not currently support; and
• Reusing existing software targeting that VM by creating a 'cgo' type calling interface.

The downside of using an existing VM is the sheer scale of the work involved:

• We have to model all of the Go-specific features into the VM's feature-set at "compile" time, which may not be a good fit, including making a 'cgo' type calling interface; and
• We have to write a Go interpreter for the target VM bitcode, which must include not just the features that Go requires, but also every other feature, in order to allow interworking with existing software modules.

Looking at some of the existing VMs we could choose:

• Dis is really interesting, not only for the circularity of Rob Pike having worked on it and it therefore containing some Go-like features, but also the possibility of hosting an entire OS in the VM. However, aside from any technical issues, the LGPL licence raises a red flag in my mind in terms of future commercial use.
• lua has the big advantage of an existing interpreter for it written in Go.
• cPython has a huge user-base.
• llvm already has the llgoi project as part of llgo.
• JVM, seen as the antithesis of Go, has a Go interpreter at https://github.com/zxh0/jvm.go (and TARDISgo generated code for it via Java).
• ...and there are many other VMs too.

But my personal choice for a VM for this project to target would be wasm because I believe this relatively new project has sufficitent support from the major players to create the de-facto standard VM - both in browsers and in servers. So a pure-Go interpreter for it is likely to get some use, as is a Go compiler and REPL built around it. Once the wasm platform is mature, I think it likely that the core compiler will target it too. In the short-term we could compile to it using cgo calls to Binaryen, which is designed to be a compiler back-end, and execute it using V8, which already has a wasm JIT-engine built-in.

[sbinet]

yes wasm and its nascent ecosystem has been on my radar.
I'll integrate your feedback in the actual design document I am still writing :)
thanks.

[sbinet]

@elliott5 PTAL

[elliott5]

I've only just started my investigations @sbinet, but the part we are interested in emu "the Inferno emulator" includes a NOTICE that does not have LGPL restrictions but does proclaim copyright for one Russ Cox.

[sbinet]

@4ad: is this tentative proposal vaguely in line with what you had in mind wrt GOARCH=vm ?

[themihai]

Package reflect has some support for this (StructOf, ArrayOf, ...) but
it currently has no support for defining new interface types nor any new named types.

It's worth to note that both named types and interface types[0] are on the roadmap.
If I would have a vote I would put it on wasm because it's more rewarding. You don't get only a VM but also instant and free support to other environments(i.e. web, IoT)

Unfortunately, there is only a work in progress C/C++ project at the moment (August 2016),
so it is probably a bit early to write code to target it.

The specs for MVP (i.e. the format) should be done by the end of this year. Unfortunately other features such GC support will start only after the MVP so I'm wondering if we can workaround these limitations until native support is provided.

[0]
golang/go#4146
golang/go#16522

[glycerine]

I think it may be worth pro-actively addressing security concerns. Dynamic code generation at runtime always broadens the security attack surface, and for internet facing programs, this does need to be managed. We need a good story here.

One thought would be to do something like the unsafe package does. To wit, unsafe can be prohibited in contexts where it needs to be.

[4ad]

@4ad: is this tentative proposal vaguely in line with what you had in mind wrt GOARCH=vm ?

I don't think so, my use case and needs are very different from yours.

I want to build an low-latency, real-time, low-throughput, non-parallel interpreter (not JIT) specifically tailored to Go and written in ANSI/POSIX C (perhaps with some assembly, but not Go), small enough that can run on today's (bigger) microcontrollers, and with special support for debugging Go, and for creating dynamic analysis tools. This interpreter will be able to function as a shared library (strange concept, coming from me), and will be able to run old code compiled by older versions of my compiler as well (binaries being forward-compatible is an explicit goal).

The instruction set will be something that is very easy to compile Go to, and something that is also very easy to implement in a performant (and portable) manner without a JIT (threaded code is still under consideration, especially for microcontrollers).

I will then port Go to this virtual machine, rewriting all the runtime, and not only writing a new compiler target, but most likely writing a new middle-end as well.

I keep using the world portable here, that doesn't mean I necessarily want my code restricted to ANSI C. It's much easier to implement performant interpreters in assembly. I just mean that porting is literally easy. It's very easy to port a threaded code interpreter to a new architectures, even if it's written in assembly, because it is very straightforward and contains very few lines of code. The inner loop is literally just a few machine instructions. That being said, I still haven't excluded the option of a pure C interpreter.

I have three main use cases for this.

Even though I keep porting Go to new systems and architectures, the gc implementation still doesn't run on many systems, and it will never run on microcontrollers. As portable the gc implementation is (and as I retargeted it a few times, I know quite a bit about this; it's getting harder and harder to do a port, the gc implementation is becoming less portable), I need a Go implementation that can be ported in maximum one day of work, and preferably less than a couple of hours of work.

I need a fully deterministic implementation of Go. This is one of the reasons I won't do a parallel implementation of Go (there are other reasons for that too).

I need hard real-time execution behavior with real-time GC. Throughput is of no concern of mine, but I plan to use Go to fly planes and rockets. Perhaps surprisingly to some, it's easier to do real-time with an interpreter.

Debugging Go code sucks. My VM will export debugging interfaces that can be targetted by gdb and other debuggers, plus it will implement a debugger itself, with full knowledge about Go internals. Very advanced (not really) features will easily be supported in an interpreter, like reliable watchpoints, always being able to find the origin of allocations, and using copy-on-write memory to find memory corruption bugs.

Sometimes I need to do dynamic analysis over Go programs. This is easy to do in an interpreter, including things like race detection.

The runtime needs to be completely rearchitected for what I want to do. The compiler is deeply entangled with the runtime. It's probably much easier to rewrite the middle-end.

There's also a deeper research goal in all this endeavour. I want to study if it's possible to have a much smaller, and much portable Go implementation, that is still competitively performant, and has an edge over the gc implementation in some niche areas. So even if I can make the gc compiler generate code for my VM, or even if I am able to reuse part of the GC, I still want to write a new compiler and a new GC just to see if I can make a smaller, more maintainable system that is good enough.

I will keep an eye on what's happening in your project, and I hope you'll keep an eye on mine.

[kardianos]

@4ad So similar to running Instruction List or Structured Text on a PLC? Would you do single thread per process and require pre-allocating slices and structures? Would you allow dynamic reloading of modules for online editing?

@sbinet Implementation options aside, what feature sets do you want to target for an interpreter?

I see five classes of use cases for an interpreter:

• A stand alone scripting env like you might expect with bash.
• A REPL for go.
• A bytecode interpreter similar to Java or C# (executes from main())
• An extension execution interpreter for existing Go programs, similar to how text/template is executed.
• A real time interpreter for control systems

Each on of these could be executed in either:

• A trusted environment where the environment (Go packages, operating system) should be exposed.
• An untrusted environment where the environment should be mostly isolated.

In each environment the following could all be features of the interpreter:

• Breakpoints
• Value inspection
• Real-time reloading of sections of code
• Line by line interpretation without full compile (REPL)
• Compile up front into bytecode that ensures no malformed input