The design and implementation of a scalable concurrent virtual machine (Robert Virding)

Erlang Solutions Ltd.

© 1999-2011 Erlang Solutions Ltd.

The Design and Implementation of a Scalable, Concurrent Virtual Machine

Robert VirdingPrinciple Language Expert at Erlang Solutions Ltd.


Erlang Solutions Ltd.

• The one stop shop for all your Erlang needs

• Founded in 1999, Offices in UK, Sweden and Poland

• Clients on six continents

• System development experience in:

- Telecom, banking, e-commerce, track & trace, VOIP, etc.

• We do:

- In-house system development, on-site consultancy, and contracting,

- Erlang-based recruitment and Professional training at all levels

2


Concurrency vs. Parallelism

• Parallelism is what the system provides

•Concurrency is a property of the problem/solution

(as good a definition as any)

3


Erlang is COP

Concurrency Oriented Programming

4


Problem domain/Erlang properties

• Light-weight concurrency

•Asynchronous message passing

• Process isolation

• Error handling

•Complex coordination

• Soft real-time

•Continuous evolution of system

5


Erlang is a functional language

• Immutable data

•No looping constructs

• Pattern matching is ubiquitous

6


Communication

•Asynchronous message passing

- Scales well

- Suits multi-core

- needs only limited synchronisation

• Each process has a single message queue

• Selective receive

• Suitable as a building block

7


The BEAM

The main Erlang implementation

Will cover:

• Processes/scheduling

•Memory management

•Communication

• Error handling

(Bogdan’s Erlang Abstract Machine, now Björn’s)

8


Processes and scheduling

•Want light-weight concurency

•Must have processes (isolation)

➡Implement processes ourselves (green processes)

•They are really light-weight

•Complete control of scheduling

•Not a general machine

9


Processes and scheduling

• Pre-emptive scheduling

- Scheduled as cooperating coroutines

•One run-queue per thread

•Multi-core/multi-thread ➡ multi-queues- Process stealing

•No really viable alternatives

10


Memory management/GC

• Soft real-time requires unobtrusive GC

•Must ensure process isolation

• Stop-the-world collector

vs.

interactive/concurrent collector

- independent of parallelism

11



Alternatives:

• Shared heap

• Separate process heaps

•Hybrid

12



Erlang does NOT require separate heaps and message copying!

• Immutable data means we can safely share

13



Shared heap

•Reduces copying of data

- Messages shared

•Complicates GC

- must use incremental/concurrent collector

• Less well-suited to multi-core

•Complicates handling of processes

14



Separate process heaps

• Increases copying of data

- messages copied

• Simplifies GC

- can use stop-the-world per process collector

• Fits well on multi-core

• Scales well

• Simplifies handling of processes

15



Hybrid heaps

•Reduces copying of data

- messages on shared heap

•May in part be determined at compile-time

•Complicates GC

• Less well-suited on multi-core

16



Erlang BEAM uses very restricted hybrid heaps

•Mainly separate heaps

- most of the benefits of separate heaps

• Some shared data

- get some benefits of shared data

- without too many of the complications

17


Alternative communication

• Share memory communication

- synchronisation woes - locking, mutexes ...

- scalability?

- error handling

• STM (Software Transactional Memory)

- scalability?

•Go concurrency motto

- "Do not communicate by sharing memory; instead, share memory by communicating"

18


Erjang - Erlang on the JVM

A real Erlang on the JVM

Will cover:

•Why the JVM?

•How it runs Erlang code

•Concurrency/scheduling

•Memory management/GC

•Miscellaneous

19


Erjang - Why the JVM?

• Erjang is different from the BEAM

- it has different properties

•Very mature VM

•Wide-spread VM

- Erlang can run in MANY more places

• Improved interface between Erlang and other JVM languages

•Access to libraries

(Kresten wanted to learn Erlang)

20


Erjang - Running Erlang code

•Uses BEAM VM assembler code as source to generate Java .class files

- helps ensure compatibility

21


Erjang - Concurrency

•Uses Kilim to provide concurrency and message passing

- ultra light-weight threads

- message passing with shared messages

•Cooperative coroutines

22


Erjang - Scheduling

• Pre-emptive scheduling

- Scheduled as cooperating coroutines

•One run-queue per thread

•Multi-core/multi-thread ➡ multi-queues

23


Erjang - Memory management/GC

•Uses standard JVM memory management/GC

- shared heap

- stop-the-world collector

➡Cannot guarantee soft real-time behaviour (yet)

☹

24


Erjang - Miscellaneous

•Needs special handling for tail-call optimisation

(a must for functional languages)

- BEAM compiler generates different calls

- two entry points for each function

- common body

25


• The Erlang User Conference brings together the best minds and names in Erlang Programming

• This year, the Erlang User Conference will be held in a brand new location – the exciting, spacious building of the München Bryggeriet.

• An enticing addition to the 2011 conference will be two further tracks.

• We will also be holding a day of tutorials on 4 November.

• In the 3 days prior to the conference, 31 October – 2 November, we will be holding an Erlang University with a selection of Erlang courses suitable for all levels of expertise.

26


Questions?

Thank you

Robert Virding

[email protected]

27

mailto:[email protected]

mailto:[email protected]

The design and implementation of a scalable concurrent virtual machine (Robert Virding)

Technology

erjang erlang

vm erlang

erlang needs

memory managementgc

jvma real erlang

erlangbased recruitment

erjang memory managementgc

memory managementgcshared