14 ms·

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

126 points by easyd 11y ago

pron 11y ago
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.
- vezzy-fnord 11y ago
  whereas in Erlang (IIRC) ETS cause some issues with GC There isn't any at all for ETS: Note that there is no automatic garbage collection for tables. Even if there are no references to a table from any process, it will not automatically be destroyed unless the owner process terminates. It can be destroyed explicitly by using delete/1. The default owner is the process that created the table. Table ownership can be transferred at process termination by using the heir option or explicitly by calling give_away/3. Of course, you'll seldom be using ETS directly, but rather through Mnesia. From: http://www.erlang.org/doc/man/ets.html http://www.erlang.org/doc/man/ets.html
  - rubyrescue 11y ago
    I've built dozens of Erlang apps and used ETS in every one. I've used Mnesia once, and it was not a pleasant experience. Most Erlang dev teams use ETS directly. It's possible to use Mnesia successfully but I see it far less often than ETS these days.
  - jlouis 11y ago
    You will be using ETS directly way more often than you will be using Mnesia in many Erlang systems, so I wouldn't really say you'll use it rarely.
- digitalzombie 11y ago
  > 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.
  - pjmlp 11y ago
    Any JVM implementation is free to choose how to do it.
  - mike_hearn 11y ago
vezzy-fnord 11y ago
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.
hendzen 11y ago
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 11y ago
  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.
- mwcampbell 11y ago
  What's wrong with colloquial style? Perhaps the usual stuffy style of academic writing is a trapping to avoid, not something to imitate and perpetuate.
ScootyPuff2000 11y ago
This is a terrible paper. It barely made a point, and is riddled with distracting misspellings and grammatical errors.
- leothekim 11y ago
  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 11y ago
    To be fair, neither the title nor the abstract suggest that a result will be presented.
jfaucett 11y ago
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 11y ago
  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 11y ago
    Do you have any links that gives recent information about the JIT? Would be interesting to read more.
white-flame 11y ago
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 11y ago
  I mean, you could always keep your large data structure in ETS?
  - white-flame 11y ago
    That's not very fast in comparison.
  - areed 11y ago
    ETS: http://www.erlang.org/doc/man/ets.html http://www.erlang.org/doc/man/ets.html
- rudiger 11y ago
  If you need a multi-gigabyte, read-only, in-memory data structure with support for ad-hoc querying and concurrent reads... you probably should just use a SQL database.
- vtuulos 11y ago
  DiscoDB does exactly what you described: It memory maps a large read-only data structure in RAM. It has an Erlang binding based on NIFs. http://discodb.readthedocs.org/en/latest/ http://discodb.readthedocs.org/en/latest/ https://github.com/discoproject/discodb https://github.com/discoproject/discodb

126 points by easyd 11y ago

pron 11y ago

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.

vezzy-fnord 11y ago
whereas in Erlang (IIRC) ETS cause some issues with GC There isn't any at all for ETS: Note that there is no automatic garbage collection for tables. Even if there are no references to a table from any process, it will not automatically be destroyed unless the owner process terminates. It can be destroyed explicitly by using delete/1. The default owner is the process that created the table. Table ownership can be transferred at process termination by using the heir option or explicitly by calling give_away/3. Of course, you'll seldom be using ETS directly, but rather through Mnesia. From: http://www.erlang.org/doc/man/ets.html http://www.erlang.org/doc/man/ets.html
- rubyrescue 11y ago
  I've built dozens of Erlang apps and used ETS in every one. I've used Mnesia once, and it was not a pleasant experience. Most Erlang dev teams use ETS directly. It's possible to use Mnesia successfully but I see it far less often than ETS these days.
- jlouis 11y ago
  You will be using ETS directly way more often than you will be using Mnesia in many Erlang systems, so I wouldn't really say you'll use it rarely.
digitalzombie 11y ago
> 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.
- pjmlp 11y ago
  Any JVM implementation is free to choose how to do it.
- mike_hearn 11y ago

vezzy-fnord 11y ago

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.

hendzen 11y ago

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 11y ago
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.
mwcampbell 11y ago
What's wrong with colloquial style? Perhaps the usual stuffy style of academic writing is a trapping to avoid, not something to imitate and perpetuate.

ScootyPuff2000 11y ago

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

leothekim 11y ago
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 11y ago
  To be fair, neither the title nor the abstract suggest that a result will be presented.

jfaucett 11y ago

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 11y ago
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 11y ago
  Do you have any links that gives recent information about the JIT? Would be interesting to read more.

white-flame 11y ago

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 11y ago
I mean, you could always keep your large data structure in ETS?
- white-flame 11y ago
  That's not very fast in comparison.
- areed 11y ago
  ETS: http://www.erlang.org/doc/man/ets.html http://www.erlang.org/doc/man/ets.html
rudiger 11y ago
If you need a multi-gigabyte, read-only, in-memory data structure with support for ad-hoc querying and concurrent reads... you probably should just use a SQL database.
vtuulos 11y ago
DiscoDB does exactly what you described: It memory maps a large read-only data structure in RAM. It has an Erlang binding based on NIFs. http://discodb.readthedocs.org/en/latest/ http://discodb.readthedocs.org/en/latest/ https://github.com/discoproject/discodb https://github.com/discoproject/discodb