Erlang vs Java

a) Introduction

Erlang run its program in its own VM, just like Java, which is independent of platform.

It is referred as concurrent language at many places because threads are part of the programming language, they do not belong to the operating system, unlike in Java. At OS level, the memory management in the operating system protects whole pages of memory, so the smallest size that a thread can be is the smallest size*usually 512KB) of a page. That's actually too big. This is 1 of the major thing Erlang has modified. Usually the memory requirements for a thread is very low in Erlang is about 512 bytes.

b) Creation of processes :

The processes in Erlang are created and handled in its VM.

Moreover, these processes do not create an OS thread for every created process and are lightweight. As a result, process creation time is of the order of microseconds and independent of the number of concurrently existing processes. While in Java, every process an underlying OS thread is created.

c) Handling of processes :

Apart from creation of processes, it is much cheaper to switch context, because they only switch at known, controlled points and therefore don't have to save the entire CPU state. It is usually single-threaded, meaning that there is no requirement to ensure thread-safety between processes. However, it now supports SMP, but the interaction between Erlang processes on the same scheduler/core is still very lightweight (there are separate run queues per core).

d) How the concurrency works in Erlang vs Java :

The current JVM uses shared heap topology. There is one big heap that is used by all threads. Most memory is allocated on that heap. In addition to the heap, the JVM uses some specialised data areas like the code cache and the permanent generation. These too are shared between all threads.

e) Block Diagram :

https://mydevelopedworld.files.wordpress.com/2012/12/message-passing-in-shared-heap-system.png?w=529&h=364

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

Block Diagram :

https://mydevelopedworld.files.w...

Aside from the private heaps, all threads share access to a so-called binary heap and a message heap. These are specialised heaps. The binary heap is for allocating large chunks of arbitrary data that are likely to be shared between threads.

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

f) Performance Tests :

It is observed that the time taken to create an Erlang process is constant 1µs up to 2,500 processes; thereafter it increases to about 3µs for up to 30,000 processes. In Java, for a small number of processes it takes about 300µs to create a process. Creating more than two thousand processes is impossible.

However, these metrics are not absolute and depends on the enviornment and the requirement.

g) Problems / Limitations against Java :

• It was observed for requirements of manjor mathematical calculations and benchmark system, Erlang is slower than Java.
• If we anyways require very less no of threads and task can be done using primitives in Java (i.e. Not Heap/GC), Java performs better
• No such active community support or libraries as in Java
• Java gives a better development features in case of enterprise level software where the workflow of the software is huge and scalability is not the only concern

h) When to use what in brief :

• Erlang was not built for math. It was built with communication, parallel processing and scalability in mind. So for projects which has high incoming request and does less processing can be built over erlang for better scalability
• Erlang can be used in case where we have a stream oriented messaging system. That’s when the Erlang programming model really shines.
• Erlang can be used when no of threads to be opened to achieve high level of parallelism is huge.