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

1,318 views
1,263 views

Published on

Published in: Technology, News & Politics
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,318
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. Robert Virding Principle Language Expert at Erlang Solutions Ltd.Erlang Solutions Ltd.The Design and Implementation ofa Scalable, Concurrent VirtualMachine © 1999-2011 Erlang Solutions Ltd.
  2. 2. 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 © 1999-2011 Erlang Solutions Ltd. 2
  3. 3. Concurrency vs. Parallelism• Parallelism is what the system provides• Concurrency is a property of the problem/ solution (as good a definition as any) © 1999-2011 Erlang Solutions Ltd. 3
  4. 4. Erlang is COPConcurrency Oriented Programming © 1999-2011 Erlang Solutions Ltd. 4
  5. 5. Problem domain/Erlang properties• Light-weight concurrency• Asynchronous message passing• Process isolation• Error handling• Complex coordination• Soft real-time• Continuous evolution of system © 1999-2011 Erlang Solutions Ltd. 5
  6. 6. Erlang is a functional language• Immutable data• No looping constructs• Pattern matching is ubiquitous © 1999-2011 Erlang Solutions Ltd. 6
  7. 7. 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 © 1999-2011 Erlang Solutions Ltd. 7
  8. 8. The BEAMThe main Erlang implementationWill cover:• Processes/scheduling• Memory management• Communication• Error handling(Bogdan’s Erlang Abstract Machine, now Björn’s) © 1999-2011 Erlang Solutions Ltd. 8
  9. 9. 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 © 1999-2011 Erlang Solutions Ltd. 9
  10. 10. 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 © 1999-2011 Erlang Solutions Ltd. 10
  11. 11. Memory management/GC• Soft real-time requires unobtrusive GC• Must ensure process isolation• Stop-the-world collector vs. interactive/concurrent collector - independent of parallelism © 1999-2011 Erlang Solutions Ltd. 11
  12. 12. Memory management/GCAlternatives:• Shared heap• Separate process heaps• Hybrid © 1999-2011 Erlang Solutions Ltd. 12
  13. 13. Memory management/GC Erlang does NOT require separate heaps and message copying!• Immutable data means we can safely share © 1999-2011 Erlang Solutions Ltd. 13
  14. 14. Memory management/GCShared heap• Reduces copying of data - Messages shared• Complicates GC - must use incremental/concurrent collector• Less well-suited to multi-core• Complicates handling of processes © 1999-2011 Erlang Solutions Ltd. 14
  15. 15. Memory management/GCSeparate 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 © 1999-2011 Erlang Solutions Ltd. 15
  16. 16. Memory management/GCHybrid 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 © 1999-2011 Erlang Solutions Ltd. 16
  17. 17. Memory management/GCErlang 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 © 1999-2011 Erlang Solutions Ltd. 17
  18. 18. 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" © 1999-2011 Erlang Solutions Ltd. 18
  19. 19. Erjang - Erlang on the JVMA real Erlang on the JVMWill cover:• Why the JVM?• How it runs Erlang code• Concurrency/scheduling• Memory management/GC• Miscellaneous © 1999-2011 Erlang Solutions Ltd. 19
  20. 20. 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) © 1999-2011 Erlang Solutions Ltd. 20
  21. 21. Erjang - Running Erlang code• Uses BEAM VM assembler code as source to generate Java .class files - helps ensure compatibility © 1999-2011 Erlang Solutions Ltd. 21
  22. 22. Erjang - Concurrency• Uses Kilim to provide concurrency and message passing - ultra light-weight threads - message passing with shared messages• Cooperative coroutines © 1999-2011 Erlang Solutions Ltd. 22
  23. 23. Erjang - Scheduling• Pre-emptive scheduling - Scheduled as cooperating coroutines• One run-queue per thread• Multi-core/multi-thread ➡ multi-queues © 1999-2011 Erlang Solutions Ltd. 23
  24. 24. Erjang - Memory management/GC• Uses standard JVM memory management/GC - shared heap - stop-the-world collector➡Cannot guarantee soft real-time behaviour (yet) ☹ © 1999-2011 Erlang Solutions Ltd. 24
  25. 25. 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 © 1999-2011 Erlang Solutions Ltd. 25
  26. 26. • 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. © 1999-2011 Erlang Solutions Ltd. 26
  27. 27. Questions? Thank you Robert Virding robert.virding@erlang-solutions.com © 1999-2011 Erlang Solutions Ltd. 27

×