Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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


Published on

Published in: Technology, News & Politics
  • Be the first to comment

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. The BEAMThe main Erlang implementationWill cover:• Processes/scheduling• Memory management• Communication• Error handling(Bogdan’s Erlang Abstract Machine) © 1999-2011 Erlang Solutions Ltd. 7
  8. 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 © 1999-2011 Erlang Solutions Ltd. 8
  9. 9. Processes and scheduling• One run-queue per thread• Scheduled as cooperating coroutines• Multi-core/multi-thread ➡ multi-queues - Process stealing• No really viable alternatives © 1999-2011 Erlang Solutions Ltd. 9
  10. 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 © 1999-2011 Erlang Solutions Ltd. 10
  11. 11. Memory management/GCAlternatives:• Shared heap• Separate process heaps• Hybrid Erlang does NOT require separate heaps and message copying! © 1999-2011 Erlang Solutions Ltd. 11
  12. 12. Memory management/GC• Shared heap• Reduces copying of data• Complicates GC - must use incremental/concurrent collector• Less well-suited to multi-core• Complicates handling of processes © 1999-2011 Erlang Solutions Ltd. 12
  13. 13. Memory management/GC• Separate process heaps• Increases copying of data• 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. 13
  14. 14. Memory management/GC• Hybrid heaps• Reduces copying of data - messages on shared heap• May in part determined at compile-time• Complicates GC• Less well-suited on multi-core• Erlang BEAM uses very restricted hybrid heaps © 1999-2011 Erlang Solutions Ltd. 14
  15. 15. Communication - asynchronousmessage passing• Scales well• Suits multi-core - needs only limited synchronisation• Suitable as a building block © 1999-2011 Erlang Solutions Ltd. 15
  16. 16. Erjang - Erlang on the JVM• A real Erlang on the JVM• Will cover:• Why the JVM?• How it runs Erlang code• How it does concurrency• How it does scheduling• Memory management/GC• Miscellaneous © 1999-2011 Erlang Solutions Ltd. 16
  17. 17. Erjang - Why the JVM?• Wide-spread VM• Very mature VM• Improved interface between Erlang and other JVM languages• Access to libraries(Kresten wanted to learn Erlang) © 1999-2011 Erlang Solutions Ltd. 17
  18. 18. Erjang - Running Erlang code• Uses BEAM VM assembler code as source to generate Java - helps ensure compatibility © 1999-2011 Erlang Solutions Ltd. 18
  19. 19. Erjang - Concurrency• Uses Kilim to provide concurrency and message passing - ??description??• Cooperative coroutines• Asynchronous message passing © 1999-2011 Erlang Solutions Ltd. 19
  20. 20. Erjang - Scheduling• One run-queue per thread• Scheduled as cooperating coroutines• Multi-core/multi-thread ➡ multi-queues © 1999-2011 Erlang Solutions Ltd. 20
  21. 21. 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. 21
  22. 22. Erjang - Miscellaneous• Needs special handling for tail-call optimisation (a must for functional languages) © 1999-2011 Erlang Solutions Ltd. 22
  23. 23. • 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. 23
  24. 24. Questions? Thank you Robert Virding © 1999-2011 Erlang Solutions Ltd. 24