Comparison of Erlang Runtime System and Java Virtual Machine [pdf]

Wouldn't it be more correct to speak of the EVM as opposed to ERTS here? ERTS defines things like the boot protocol, distribution protocol, term serialization, port drivers, NIFs and BIFs. Though when talking about scheduling semantics, that's on the EVM level (to differentiate it from BEAM in particular).

Otherwise, a decent high-level overview.

The report mentions Quasar (I'm its main author) and simply says, "instrumentation has many challenges that add complexity to the program instead of removing it." -- without mentioning why. I believe this is false. Quasar removes just as much complexity as Erlang does (Erlang's enforcement of immutability is orthogonal; indeed, if you use Quasar with Clojure you get that, too), but it is true that the instrumentation is not entirely transparent -- yet. This doesn't add any complexity to the program (the code is exactly the same as it would be in Erlang), but it does add some difficulty to the compilation process, as all blocking methods must be annotated. This is an annoyance, but it will probably go away in Java 9, as we are working with Oracle to make a minor change to the JVM (no, unfortunately not building continuations into the JVM just yet) that will make the bytecode instrumentation process fully automatic and completely transparent.

Fibers implemented with bytecode instrumentation also have some (small) added overhead (which is why we'd like them to be built directly into the JVM), but this makes little difference in practice: HotSpot's compiler is so good that with any added real work, that overhead is becomes negligent, and the compilation quality means that overall performance exceeds anything that can be achieved by Erlang VMs.

Also, the report says: "the JVM has a single heap and sharing state between concurrent parties is done via locks that guarantee mutual exclusion to a specific memory area. This means that the burden of guaranteeing correct access to shared variables lies on the programmer, who must guard the critical sections by locks". This is grossly inaccurate. While it is true that the JVM has a shared heap, this means that it can allow programs to share mutable state among threads -- not that it necessarily does so. The JVM leaves the concurrency model up to the language implemented on top of it (just as the hardware and OS support a shared heap, but various languages may choose not to expose that as a visible abstraction to program code). E.g. Clojure only allows shared mutable state if it enforces transactional modifications. Erlang also allows this kind of shared state via ETS; the difference is that ETS must be programmed in C, whereas on the JVM you can write the shared data structure in a JVM language. This also means that on the JVM, objects stored in such a concurrent data structures are handled by the GC, whereas in Erlang (IIRC) ETS cause some issues with GC (EDIT: in fact, ETS data is not garbage collected at all).

I believe that the JVM is a strict superset of any Erlang VM. In particular, HotSpot (the OpenJDK's JVM) is so well implemented, that the main difference -- even when running programs that behave just like Erlang program -- is a huge boost in performance, and never needing to use C to achieve either good performance or some behavior that is unsupported by Erlang semantics.

whereas in Erlang (IIRC) ETS cause some issues with GC

There isn't any at all for ETS:

   Note that there is no automatic garbage collection for
   tables. Even if there are no references to a table from
   any process, it will not automatically be destroyed
   unless the owner process terminates. It can be destroyed
   explicitly by using delete/1. The default owner is the
   process that created the table. Table ownership can be
   transferred at process termination by using the heir
   option or explicitly by calling give_away/3.

Of course, you'll seldom be using ETS directly, but rather through Mnesia.

From: http://www.erlang.org/doc/man/ets.html

It reads like it was written by an undergraduate for independent study credit, or as a lit review for a future non-doctoral thesis. Certainly no result here, just a survey.

> I believe that the JVM is a strict superset of any Erlang VM.

I don't get how JVM is a strict superset of Erlang VM when it doesn't have pre-emption.

If BEAM set have preemptive scheduler as an element and JVM, IIRC, does not have such feature, then JVM is not a super set let alone a strict super set.