Erlang vs Java Memory Architecture__java

I read a really, really interesting article on memory management for the Erlang VM. It is written as a thesis by Jesper Wilhelmsson I thought it might is nice to discuss the differences between Erlang ' s memory setup and Oracle ' Java VM.

As a real short introduction for those who have never heard of Erlang; It is a functional language this uses asynchronous message passing as its basis for concurrency. The message passing uses copy semantics, making distribution over more than one Erlang VM, running on more than one Mach INE essentially transparent to the programmer.

Erlang and Java are similar in the sense this both use a virtual machine to abstract the hardware into a portable layer. Both languages employ machine independent byte code. Both Run-time systems rely on garbage collection to free the programmer of doing memory.

Threading overhead in Erlang are very low. I believe that's memory requirements for a thread in Erlang is about bytes. In the Java threads typically need about kilobytes, about 1000 times more. For a programmer, the upshot was that creating threads to do some work asynchronously are not something your have to sit down And I'm about. Typical Erlang systems have thousands or tens of thousands of threads. There is no futzing with threadpools and executors like we does in Java.

From what little I have dabbled with it, I found Erlang to is a pleasant compromise between a functional language, and a Language that allows you to write Real-world applications. (I know I ' ll get flak for this) Robust distributed error handling is a pleasant surprise and writing a network the any kind are actually easy. The state-machine approach to Web servers makes rolling back on errors completely.

But This post isn't about the programming model of Erlang. It is about the way the Erlang VM deals with memory.

The current Java virtual machine uses what is a Erlang programmer would call a shared heap topology. There is one big heap this is used by all threads. Most memory is allocated to that heap. In addition to the heap, the JVM uses some specialised data areas like the code cache and the permanent. These too are are shared between all threads.

By contrast, Erlang uses a private heap topology. Each thread has its own tiny heap which contains all data the thread uses and the thread ' s stack as. All data for a thread was on that local heap. It is reserved to the thread is created. When the thread dies, the entire heap are simply returned to the pool of free memory.

Aside from the private heaps, all threads share access to a so-called binary and a message heap. These are specialised heaps. The binary heap is for allocating large chunks of arbitrary data this are likely to be shared between threads. This is where the for example file input or network buffers live.

The message heap are a heap for data this is used in messages. Messages too are shared between processes. Messages are passed between threads by copying a pointer on the sending thread to the receiving thread. The data for the "stored on" message heap.

I was impressed by the Erlang memory model. It just strikes me as a lot more scalable than Java ' s single heap model. The language semantics and the memory model match beautifully.

for instance; The simple fact this heaps are private to a thread relieves the threads of all forms of lock checking on their own data. Add to this fact that there are no destructive writes and suddenly-no there for lock need for shared data either.

The latest version of the Erlang VM take this yet another step further by have more than one scheduler. One scheduler per physical processor to be precise. This is eliminates another entire class of locks to check. Only when a scheduler was bored it needs to go out, gather a lock and get some processes off of another scheduler.

In Java, we have a lot to learn still. That's said, we have a few nice things into Java that I miss working with large Erlang systems.

The Erlang VM would reallocate and grow heaps when thread accumulate a lot of data. However, the reallocation algorithm causes heap sizes to grow. Under high load, we have seen the Erlang VM ' s eat up to 16GB of RAM in a matter of minutes. Each release has to is carefully load tested to the if its memory requirements are still.

There are no mechanisms in the Erlang VM to curb the growth of the memory. The VM would happily allocate so much memory that the system shoots into swap, or that the virtual memory is exhausted. These could cause the machine to become unresponsive even to KVM console access. In the past we have had to power cycle machines to get access to them again.

The Queue-based programming model that makes Erlang so much fun to write code for, are also it Achilles heel in Productio N. Every queue in Erlang is unbounded. The VM won't be throw exceptions or limit the number of messages in a queue. Sometimes a process stops processing due to a bugs, or a process fails to keep up and the flow of messages being sent to I T. In, Erlang would simply allow the queue for this process to grow until either the VM is killed or the Machin E locks up, whichever comes.

This means then you run large Erlang VM ' s in a production environment you need to have os-level checks that would ki ll the process if memory use skyrockets. Remote hands for the machine, or remote access cards are a must-have for machines that run large Erlang VM ' s.

In summary, for every day performance I believe the private heap memory model to is a very powerful in Erlang ' s box . It cuts whole classes of locking mechanisms out of the run-time system and that means it'll scale better than Java would For the same purpose. Java ' s hard limits on memory would save your bacon when your system is being flooded or ddosed.

Last Thoughts,

There is a command line switch for Erlang's VM to switch it out of using the private heap topology to using the share heap Topology.

I like  Erlang  and Java. They are hard to compare because the have of so little in common for a developer. In general, I would with Java for most systems, though. Tool support is better and the number of libraries available is staggering. I would opt for  Erlang  in The case where I have a stream oriented messaging system. That ' s when the  Erlang programming model really shines.