Comparison of Erlang Runtime System and Java Virtual Machine [pdf] | Hacker News Reader

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

ds.cs.ut.ee

65 pointscurtas12 comments

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

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

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

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

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

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)?

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

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.

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

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.

You can use JVM fibers now with Quasar and Comsat, and Guava provides a whole cast of immutable data structures.

Direct support would be more efficient but because of Java's heavy JIT'ing you can get near native performance now

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.

Can Erlang share memory between threads?

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

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.

Reply on news.ycombinator.com