Basically, building real-time fault-tolerance support on top
of the JVM is by definition impossible, because the JVM
itself is not fault-tolerant.
This isn't strictly correct. The article talks about the big difference between the JVM and Erlang being a shared heap vs multiple heaps, but really, it just comes down to coding. There is nothing stopping you from using message passing and immutability in the JVM, and many libraries (eg Scala Actors) do exactly this.
So it's definitely not impossible to build fault tolerance on the JVM.
Also the diagram showing Erlang acting on any number of CPUs while Java is somehow limited to 2 CPUs is simply a marketing lie and is very unnecessary. The JVM can scale happily to any number of CPUs, as it piggy backs off native OS threads, which in linux/windows both scale to any number of CPUs.
You can try to have fault-tolerance in the JVM, but not real-time fault-tolerance, and there is a difference. The goal is to have decent performance while being fault-tolerant. The JVM garbage collection prevents real-time fault-tolerance when using an Actor model within the JVM.
Can you explain this concept in a bit more detail? There is nothing I can find to back this up anywhere, and the idea seems very strange to me as I've never heard of it before. A quick Google search on the topic seems to show a number of papers detailing real time fault tolerance on Java.[1]
At any rate, as far as I can tell CloudI is mainly intended for network and web systems, which are not going to be real time when running on Linux/Windows in any event. (network buffers, etc)
CloudI and Erlang underneath are focused on soft real-time. For hard real-time (embedded) you need tighter integration with hardware. While it is true that people attempt to pursue (soft) real-time fault-tolerance on the JVM, the point in the CloudI article is that the pursuit does not achieve fault-tolerance which can be considered real-time, simply due to the JVM garbage collection which must interrupt real-time processing of an Actor model. This problem isn't often discussed, but is a simple way of showing the problems with fault-tolerance on the JVM. Without the JVM supporting fault-tolerance, the effort to have decent (real-time) fault-tolerance would be similar to creating a new VM. Since creating a VM is difficult to do properly, and testing is required after its completion, it makes much more sense to use the Erlang VM since it has native real-time fault-tolerance that is already used in commercial products.
Comments
So it's definitely not impossible to build fault tolerance on the JVM.
Also the diagram showing Erlang acting on any number of CPUs while Java is somehow limited to 2 CPUs is simply a marketing lie and is very unnecessary. The JVM can scale happily to any number of CPUs, as it piggy backs off native OS threads, which in linux/windows both scale to any number of CPUs.
You can try to have fault-tolerance in the JVM, but not real-time fault-tolerance, and there is a difference. The goal is to have decent performance while being fault-tolerant. The JVM garbage collection prevents real-time fault-tolerance when using an Actor model within the JVM.
Can you explain this concept in a bit more detail? There is nothing I can find to back this up anywhere, and the idea seems very strange to me as I've never heard of it before. A quick Google search on the topic seems to show a number of papers detailing real time fault tolerance on Java.[1]
At any rate, as far as I can tell CloudI is mainly intended for network and web systems, which are not going to be real time when running on Linux/Windows in any event. (network buffers, etc)
[1]
http://dl.acm.org/citation.cfm?id=1404893
https://weblogs.java.net/blog/editor/archive/2013/03/18/jona...
http://books.google.co.za/books?id=BroUpHAZThwC&pg=PA470&lpg...
CloudI and Erlang underneath are focused on soft real-time. For hard real-time (embedded) you need tighter integration with hardware. While it is true that people attempt to pursue (soft) real-time fault-tolerance on the JVM, the point in the CloudI article is that the pursuit does not achieve fault-tolerance which can be considered real-time, simply due to the JVM garbage collection which must interrupt real-time processing of an Actor model. This problem isn't often discussed, but is a simple way of showing the problems with fault-tolerance on the JVM. Without the JVM supporting fault-tolerance, the effort to have decent (real-time) fault-tolerance would be similar to creating a new VM. Since creating a VM is difficult to do properly, and testing is required after its completion, it makes much more sense to use the Erlang VM since it has native real-time fault-tolerance that is already used in commercial products.