Menu
I’ve begun studying Erlang and find the BEAM runtime environment fascinating. It’s commonly stated that in Erlang, processes belong to the language rather than the OS (meaning the runtime, meaning BEAM in this case). These are the lightweight, “green processes” that Erlang is getting famous for. It’s further stated (on page 5 of this paper) that BEAM uses one (1) OS thread per CPU core for scheduling and another OS thread for i/o. So I wonder: From what thread do the CPU cycles needed to actually execute the Erlang code come from?
Further, if I’m running on a dual core machine I would expect -- based on what I’ve read so far -- to see three (3) threads running under the BEAM process: two schedulers (one for each core) and one i/o thread. But I see 10. Sometimes 11. Sometimes it starts at 13 and, like high-quality amplifiers, goes to 11.
I’m confused. Any insight will be appreciated.
555
BEAM is the virtual machine at the core of the Erlang Open Telecom Platform (OTP). BEAM is part of the Erlang Run-Time System (ERTS), which compiles Erlang source code into bytecode, which is then executed on the BEAM. BEAM bytecode files have the . beam file extension.
The BEAM has an instruction for decrementing the "reduction counter" for the process and deciding whether it is time to yield to let another process run. JVM on the other hand has synchronization instructions for threads. One important difference is that BEAM has tail call instructions, which JVM lacks.
The BEAM uses one OS thread per core. It runs a scheduler on each of these threads. Each scheduler pulls processes to run from its very own run queue. The BEAM is also responsible for populating these run queues with Erlang processes to execute.
BEAM stands for Bogdan/Björn's Erlang Abstract Machine, which is the virtual machine at the core of the Erlang Open Telecom Platform (OTP).
Following @user425720's advice, I asked my question on the erlang-questions LISTSERV. It's also available as a Google Group. Kresten Krab Thorup of Trifork answered me almost at once. My thanks to go out to Kreston. Here is his answer. (Parentheticals and emphasis are mine.)
Here is AFAIK, the basic scenario:
Erlang code will be run in as many "green threads" as there are processes; the process limit is controlled by the +P (command line) flag.
The green threads are mapped on to S threads, where S is the number of cores/CPUs. The fact that these threads are also called schedulers can seem somewhat confusing, but from the VMs point of view they are. From the developer's point of view, they are the threads that run your erlang code. The number S can be controlled with the +S option to the erl command line.
In addition hereto, there are a number of so-called "Async Threads". That's a thread pool which is used by I/O processes called linked in drivers, to react to select / poll etc. The number of asynch threads is dynamic, but limited by the +A flag.
So, the 11 threads you see on a dual-core may be 2 schedulers, and 9 async threads. For instance.
Read more about the flags here.
90
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
