Live data from Hacker News

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

ds.cs.ut.ee

1–10 of 13 posts

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

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

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

#4
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

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

#5
post #4

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.

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

#6
post #4

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

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

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

#7
post #3

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 red…

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

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

#10
post #9
post #8

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.

Post reply on HN