A New Contributor
I am extremely happy no now have a really substantial contribution from Erik, who have made significant improvements to the exception handling translation, and moved us several steps closer to the OTP boot prompt. OTP boot progress is now at 85.5% and compile progress is at 92.5%. Thanks!
All the while Erik has been busy doing a lot of stuff, all I have done the last three weeks has been to hunt down a single off-by-one error, but it was very difficult to debug. Line-level debugging with breakpoints would indeed be wonderful!
Going forward
I think we will soon be at the point where Erjang can get to the OTP boot prompt, and that will be a major milestone. From there, it will be much easier for people to pick up Erjang and try some real stuff, write unit tests, etc.
Here is a (more or less) random list of things that I think would be interesting to work on going forward with Erjang.
Unit Testing
The first thing to do when we reach the boot prompt is to make a setup for unit tests; so that there is a simple way to add new erlang code to a unit testing framework.
Bytecode Interpreter
Joe has suggested this several times, to do a bytecode interpreter as part of Erjang. One of the reasons people don't use HiPE much (he says) is that it uses a lot more memory [for code presumably]. This will likely be the same for Erjang, where the compiled code presently uses ~3-4 x the java byte code compared to beam code. A mixed-mode runtime which starts out interpreted, selectively compiling code hotspot-style would probably be good. That would also allow us to do even more inlining of non-external calls, and also inlining of the call sequences needed to realize tail recursion semantics. That would reduce the overhead of the code injected by Kilim too.
As part of HotRuby I have done this mixed-mode vm style before, and there it was possible to match the performance of MRI (ast-interpreter) in a byte-code interpreter written in Java. So this project would indeed be entirely doable.
Compile from Abstract Representation
At present, compiled beam code has no line number information and also no local-variable names. Compiling from abstract representation (which is present in beam files compiled with +debug_info) would allow us to add that. We likely need both the beam compiler and and the abstract representation compiler because it cannot be assumed that all files are compiled with with debug info flag.
This feature could likely make erjang very attractive as it would allow you to use Java debuggers with single stepping and variable presentation.
A .beam file reader
I think we need to look into writing a pure Java beam file reader too. Right now we depend on lib_beam to interpret beam code, and that is indeed fine to get up and running, but I think we can do several things more cleanly if we have the ability to read and understand beam files in the vm directly. There is a lot of code in beam_* modules, so this is not a trivial task.
And now, ... back to my day job.
