Interpreter improvements

[dmlloyd]

The initial interpreter is basically a graph iterator which keeps stack frames as hash maps mapping Value to boxed Objects. This might end up being good enough, but I doubt it. We will likely want to come up with a better interpreter that JIT-compiles code blocks into bytecode to run on the host JVM.

@headius and @enebo have taken some initial looks at what this might entail.

Since it is expected that the initial interpreter will suffice for the purposes of the initial implementation, there is no milestone on this issue.

[dmlloyd]

A basic design could look like this:

• Generate a class for each method body which represents the stack frame; stack frame instances would implement a common interface or superclass, and would form a linked list representing the call stack, with a field for each value slot (i.e. an unlimited-register machine).
• Generate a class for each object, perhaps with a degree of mapping between the virtual type hierarchy and the generated concrete type hierarchy; the generated class would include fields that mirror the virtual type's fields, and methods that correspond to the virtual type's methods with added parameters for the caller's frame and possibly the current thread.

This design would avoid the need to employ a register allocator or other potentially complex/time-consuming analysis steps, at the expense of build-time memory footprint (but note that this is still much better than the map-based approach being used right now). Since the majority of build time code is expected to execute few times (often just once), this seems like a fair tradeoff.

[dmlloyd]

Another option would be to eschew the stack frame class in favor of using local variables directly, but some solution for stack walking would still be necessary (for building exception stack traces if nothing else). Walking the real stack using the host's StackWalker and mapping each frame to a virtual frame is one possible solution.

[dmlloyd]

Done.