Comparison of Erlang Runtime System and Java Virtual Machine [pdf]
1–10 of 13 posts
Re: Comparison of Erlang Runtime System and Java Virtual Machine [pdf]
#2That's a great quote(citation is in the paper), I'll have to remember it for future use.
Re: Comparison of Erlang Runtime System and Java Virtual Machine [pdf]
#3For 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]
#4JVM 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.
Re: Comparison of Erlang Runtime System and Java Virtual Machine [pdf]
#5Most 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]
#6Most 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
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]
#7I 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…
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]
#8Re: Comparison of Erlang Runtime System and Java Virtual Machine [pdf]
#9Can Erlang share memory between threads?
Re: Comparison of Erlang Runtime System and Java Virtual Machine [pdf]
#10Can Erlang share memory between threads?
No, Erlang can only send messages between it's processes. Java can share.
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.