You beat me to it. My first reaction was "Wait - how is preserving Erlang's syntax but losing the VM a good thing?". I'd love projects going the other direction - a more modern syntax built on Erlang's rock-solid VM + OTP libraries.
I don't see a problem with process isolation ... you can control the bytecode generated from the compiler, and then you make the Java FFI really hard to please.
Since Erlang uses light-weight processes, this is exactly what the Erlang VM is doing.
In Erjang, every node runs on a single heap, and so global gc will sometimes happen.
On the other hand, Erjang does not copy messages between processes — they are simply shared, and so that might leave some room for savings.
Will be interesting to see what happens, no doubt. Message copying will have to be implemented, anyway, for inter-node communication.
I don’t know how Java’s various garbage collector compares to the one in Erlang, but I guess that Java’s is significantly faster.
Doubtful. A garbage collector specially designed for small heaps, running on such, will outperform Java's general-purpose ones. Also, Erlang's GC is stop-the-world (where "world" here is an Erlang process), and that yields numerous benefits. I think Java's GC will not be better for erjang.
Right, and due to Erlang's lightweight processes, it's not unusual to have a process finish before it needs to do any garbage collection. You can tune for this by spawning a process with a larger heap than the default - if you know that it tends to grow up to a certain size and then finish, you can just spawn it with that much to start and it will skip GC entirely.
This doesn't make much practical sense. However, implementing Erlang on top of the JVM seems like an awesome way to learn Erlang and JVM internals at the same time.
I'm curious as to what effect Java's crappy tail recursion has I tried running a ruby sudoku solver in jruby that functions basically like an n-queens solver and it couldn't handle it. Not sure I'd expect erjang to do better since the issue is with the jvm.
Tail-recursion can be implemented on top of the JVM.
For self-recursion you just issue a GOTO. For mutual recursion, the compiler can generate a trampoline.
There are two problems with a trampoline ... one is that the stack-trace will no longer be accurate. And the second problem is that interoperability with Java suffers because the bytecode of the method or that of the call-site will be different from what-you-see in your code.
For example one way of doing it is to modify the recursive function ... fn (a) => b ... to be ... fn (a) => M[b] ... where M[b] contains either the returned value "b" or the reference + arguments of the next call done by the trampoline. And then the compiler modifies the call-sites to call the trampoline instead of our method.
About efficiency ... if you want to have a generic trampoline module (instead of many trampolines defined for each group ... which would consume permgen memory), you could implement such a trampoline on top of the new invokedynamic support in JDK7 ... this could allow for the call-sites in the trampoline to be cached and ultimately JITed. I'm not sure if invokedynamic could help here (I know little about how the call-sites will be cached) but I don't see why not.
I wonder how things like process isolation will work out.