
Comparison of Erlang Runtime System and Java Virtual Machine [pdf] - easyd
http://ds.cs.ut.ee/courses/course-files/To303nis%20Pool%20.pdf
======
jfaucett
This was an decent comparison / contrast. It did make me wonder how they're
coming along with the BEAM jit these days, I found this from a while back:
[http://www.erlang-factory.com/euc2014/frej-drejhammar](http://www.erlang-
factory.com/euc2014/frej-drejhammar)

It also reminded me how much I wish there was an actual specification for
BEAM, finding out the details of the how the bytecodes work is an arduous task
compared to the JVM where everything is explicitly stated. IMHO both VMs are
excellent in their own right, the HotSpot JIT is incredible, but I still can't
deny that I find the beam process model on concurrency more elegant than the
JVM one, though in practice I've only toyed in erlang so I have no real-world
grounds of comparison there. Does anyone by chance?

~~~
jlouis
Frej's JIT is going strong! Maybe it will be present experimentally in the
next Erlang release. But such things may change over time.

~~~
Skinney
Do you have any links that gives recent information about the JIT? Would be
interesting to read more.

------
vezzy-fnord
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.

------
white-flame
I was working with Erlang for about 2 years in a multi-language environment,
and we based our networking messaging infrastructure on top of the Erlang
protocol. It's still there, but we're migrating from it.

One major thing that turned me off of the language for our particular project
was that there was no way to have a large read-only data structure in RAM and
sic a bunch of parallel threads to analyze or search it. It is hackable if you
mash your data structure into a large byte binary, since large bins live on a
shared heap, but it's a pain to deal with non-native representation for your
data.

It's very obvious that Erlang is optimized for a particular usage model, and
even when you're dealing with a number of functional parallel processes, it
might still clash with what you're doing.

~~~
sargun
I mean, you could always keep your large data structure in ETS?

~~~
areed
ETS:
[http://www.erlang.org/doc/man/ets.html](http://www.erlang.org/doc/man/ets.html)

------
hendzen
The content is quite interesting, but this paper could use some serious
editing. There are typos throughout, and the tone is overly colloquial for an
academic context.

The paper could also use an evaluation section - e.g. implementing a solution
to a well known problem like the Dining Philosophers in both languages and
comparing both the code and runtime characteristics.

~~~
kkirsche
I strongly disagree in regards to the colloquial aspect you mentioned.
Academic papers have no reason to be pompous or high level and can benefit
from increased visibility by presenting the findings in a more colloquial
manner.

------
pron
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.

~~~
digitalzombie
> 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.

~~~
pron
Quasar does preemptive scheduling, and even used to have time-slice based
preemption. The latter was taken out as it proved to provide no benefit
whatsoever, because processes that benefit from time-slice preemption are
better off using the kernel's scheduler anyway, and the JVM gives them that
option. Erlang has to do it because it only exposes a single scheduler. That's
is still a strict subset of the JVM's capabilities.

~~~
azth
> and the JVM gives them that option

By using java.lang.Thread?

~~~
pron
Yep. Both Thread and Fiber are abstracted into a Strand. So
Strand.currentStrand returns the current fiber/thread, Strand.sleep sleeps
etc.. Locks and channels work with strands, too, so that both fibers and
threads can synchronize on the same data, and even actors are assigned to a
strand, so that an actor can run in either a fiber or a thread.

Then, you pick the strand implementation (lightweight or heavyweight) --
heavyweight for computation-heavy code like video encoding, lightweight for
anything that blocks often -- and if you pick a fiber you can further select a
particular scheduler, with the default being work-stealing (like in Erlang or
Go), but you can plug your own (and control such stuff as CPU pinning for
certain schedulers).

------
ScootyPuff2000
This is a terrible paper. It barely made a point, and is riddled with
distracting misspellings and grammatical errors.

~~~
leothekim
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.

~~~
ams6110
To be fair, neither the title nor the abstract suggest that a result will be
presented.

