Concurrency in Erlang (Vs Java) :: Creation of Processes

Erlang uses lightweight processes that have their own private heaps, allowing for much faster process creation and context switching compared to Java. In Erlang, processes are created in microseconds independently of the total number of processes, while in Java process creation takes hundreds of microseconds for small numbers of processes. Erlang's message passing architecture allows processes to communicate without shared state, improving concurrency over Java's shared heap approach. However, Java can perform better than Erlang for tasks requiring significant computation rather than concurrency. Erlang is well-suited for building scalable and resilient systems that handle high volumes of requests through parallel processing.

Uploaded by

Anonymous IydVgo2

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

28 views2 pages

Concurrency in Erlang (Vs Java) :: Creation of Processes

Uploaded by

Anonymous IydVgo2

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

You are on page 1/ 2

Concurrency in Erlang (vs Java) :

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.

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.

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 singlethreaded, 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).

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.
Block Diagram : https://mydevelopedworld.files.wordpress.com/2012/12/message-passing-inshared-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 threads 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.wordpress.com/2012/12/memory-arch-privateheaps.png?w=300&h=206
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.

Performance Tests :
It is observed that the time taken to create an Erlang process is constant 1s up to 2,500
processes; thereafter it increases to about 3s for up to 30,000 processes. In Java, for a small
number of processes it takes about 300s 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.

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

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. Thats
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.