
Comparison of Erlang Runtime System and Java Virtual Machine [pdf] - curtas
https://ds.cs.ut.ee/courses/course-files/To303nis%20Pool%20.pdf
======
haglin
It may be worth mentioning that project Loom [1][2] aims to add continuations
and lightweight threading to Java. It is lead by Ron Pressler, the author of
the Quasar library mentioned in the paper.

Also, JDK 11 (Hotspot) comes with a new concurrent non-generational garbage
collector (ZGC) [3] that has an average pause time of 1 ms [4]. It is still an
experimental feature, but that will most likely change over time.

[1] [http://cr.openjdk.java.net/~rpressler/loom/Loom-
Proposal.htm...](http://cr.openjdk.java.net/~rpressler/loom/Loom-
Proposal.html)

[2]
[http://openjdk.java.net/projects/loom/](http://openjdk.java.net/projects/loom/)

[3] [http://openjdk.java.net/jeps/333](http://openjdk.java.net/jeps/333)

[4]
[https://youtu.be/tShc0dyFtgw?t=4m58s](https://youtu.be/tShc0dyFtgw?t=4m58s)

------
vvanders
> "Erlang is to locks what Java is to pointers"

That's a great quote(citation is in the paper), I'll have to remember it for
future use.

------
dgllghr
I never used a JVM language before the JIT compiler, so I have no personal
experience with the speedup it introduced. But if Lua (and LuaJIT) are any
indication, I am super excited for BEAMJIT.

For BEAMJIT, I can imagine that the same work will take a different number of
reductions before and after the JIT compiler has modified the code. Are there
going to be any scheduling issues that will arise because of these reduction
changes (or any other aspects of the JIT compiler)?

~~~
Const-me
> I never used a JVM language before the JIT compiler, so I have no personal
> experience with the speedup it introduced

Speedup in runtime, slowdown on startup. Early versions of Android (before 2.2
i.e. before 2010) used Dalvik JVM that interpreted the byte code.

BTW, apparently google still can’t decide what’s the best way. After couple of
years, in 2013-14, Google threw away the JIT and introduced another JVM, with
AOT compilation instead of JIT.

After another couple of years, in 2016, Google re-introduced JIT to the new
JVM while keeping the AOT. It’s complicated but AFAIK they work together on
modern Android.

~~~
pjmlp
The AOT compiler introduced with ART wasn't a clever decision.

When Microsoft introduced AOT compilation from Singularity into Windows 8, the
compilation was done at the store, with dynamic linking done on-device.

Windows 10 UWP brought full static compilation on the store via .NET Native.

Google instead decided to do AOT compilation on the devices, which meant users
had to wait several minutes, or even hours after major updates took place.

So with 7.0 they backtracked, using a quick interpreter written in Assembly,
followed with a JIT doing PGO, which then took the overall information to feed
into the AOT compiler, only called when the device is resting.

Updates trigger the process from the beginning.

Now with P, they will be sending PGO metada back to the store and share it
between devices at installation time.

Yet, WP devices with AOT compilation at the store always felt faster as
comparable Android class models.

------
cmjqol
Most of the problems raised in this paper from 2015 have been acknowledge by
the JVM architect in a 2017 talk[0] , and are know in the work of getting
fixed.

JVM is getting Fibers , Non Mutable Array (which would prevent from race
condition) and other important upgrade to make the VM safer and faster.

Obviously this will take years before being ready.

[0][https://www.youtube.com/watch?v=OMk5KoUIOy4](https://www.youtube.com/watch?v=OMk5KoUIOy4)

~~~
zzzcpan
In the talk (starts at 24:50) he speaks about adding something like goroutines
to JVM and expresses his belief that it can somehow solve concurrency. It
solves basically nothing mentioned in the paper, since paper's focus is on
fundamental shared state concurrency problems and sharing state won't change a
bit.

------
hsienmaneja
Isn’t beam still slow for computations? I envisioned doing something with
NIF’s, rustler and rust to break out anything computationally intensive.

Perhaps jvm is still a better purpose tool due to this.

------
bullen
Can Erlang share memory between threads?

~~~
gleenn
No, Erlang can only send messages between it's processes. Java can share.

~~~
SEMW
To clarify that a bit -- while the semantics are that erlang can only send
messages between processes, what the BEAM actually does under the hood can
certainly involve memory sharing, for efficiency reasons. E.g. binaries >64
bytes are stored outside of the individual process heaps, and are just sent as
references rather than actually copied (unless sent to a proc on another node
in a mesh, of course).

Since everything's immutable, from the programmer's point of view the
behaviour is identical to if it was copied, so the sharing is an
implementation detail that doesn't affect the semantics.

