Erlang/OTP R16 is a new major release with a number of new features, characteristics and also some minor incompatibilities.

Some remarkable improvements having a huge effect on scalability:

• New internal process table implementation allowing for both parallel reads as well as writes. Especially read operations have become really cheap. This reduce contention in various situations. For example when, spawning processes, terminating processes, sending messages, creating ports, terminating, ports, etc.
• Optimizations of run queue management reducing contention.
• Optimizations of process state changes reducing contention.
• Non-blocking code loading. Earlier when an Erlang module was loaded, all other execution in the VM were halted while the load operation was carried out in single threaded mode. Now modules are loaded without blocking the VM. Processes may continue executing undisturbed in parallel during the entire load operation. The load operation is completed by making the loaded code visible to all processes in a consistent way with one single atomic instruction. Non-blocking code loading will improve realtime characteristics when modules are loaded/upgraded on a running multi-core system.
• Dynamic allocation of port structures. This allow for a much larger maximum amount of ports allowed as a default. The previous default of 1024 has been raised to 65536.
• Major rewrite of scheduling of port tasks. Major benefits of the rewrite are reduced contention on run queue locks, and reduced amount of memory allocation operations needed. The rewrite was also necessary in order to make it possible to schedule signals from processes to ports.
• Rewrite of all process to port signal implementations in order to make it possible to schedule those operations. All port operations can now be scheduled which allows for reduced lock contention on the port lock as well as truly asynchronous communication with ports. The previous implementation of the VM has delivered signals from processes to ports in a synchronous stricter fashion than required by the language. As of Erlang R16, signals are truly asynchronously delivered.
• The runtime system will now by default use 10 async threads if thread support has been enabled when building the runtime system. This will prevent long blocking file-operations from blocking scheduler threads for long periods of time, which can be harmful. Apart from file-operations, it also effects other operations scheduled on the async thread pool by user implemented drivers. Multiple concurrent accesses to different files have the potential of an increased throughput.