aboutsummaryrefslogtreecommitdiffstats
path: root/erts/emulator/beam/msg_instrs.tab
AgeCommit message (Collapse)Author
2019-03-28erts: Fix bug in process_info(reductions)Sverker Eriksson
returning incorrect result as * current process might not be RUNNING in which case REDS_IN is actually used as def_arg_reg[5] * FCALLS might not have been swapped out * the SAVED_CALLS case was wrong and returned number of reds left
2018-04-27Merge branch 'rickard/process_info/OTP-14966'Rickard Green
* rickard/process_info/OTP-14966: Fix scheduled process_info() 'status' request Fix handling of process-info requests in receive
2018-04-26Fix handling of process-info requests in receiveRickard Green
2018-04-13Merge branch 'rickard/process_info/OTP-14966'Rickard Green
* rickard/process_info/OTP-14966: New process_info() implementation using signals
2018-04-12New process_info() implementation using signalsRickard Green
2018-03-27Merge pull request #1760 from ↵John Högberg
jhogberg/john/erts/any-term-as-seq_trace-label/OTP-14899 Lift the type restrictions on seq_trace token labels
2018-03-23Fix VM probes compilationJohn Högberg
2018-03-23Lift the type restrictions on seq_trace token labelsJohn Högberg
OTP-14899
2018-03-21Implementation of true asynchronous signaling between processesRickard Green
Communication between Erlang processes has conceptually always been performed through asynchronous signaling. The runtime system implementation has however previously preformed most operation synchronously. In a system with only one true thread of execution, this is not problematic (often the opposite). In a system with multiple threads of execution (as current runtime system implementation with SMP support) it becomes problematic. This since it often involves locking of structures when updating them which in turn cause resource contention. Utilizing true asynchronous communication often avoids these resource contention issues. The case that triggered this change was contention on the link lock due to frequent updates of the monitor trees during communication with a frequently used server. The signal order delivery guarantees of the language makes it hard to change the implementation of only some signals to use true asynchronous signaling. Therefore the implementations of (almost) all signals have been changed. Currently the following signals have been implemented as true asynchronous signals: - Message signals - Exit signals - Monitor signals - Demonitor signals - Monitor triggered signals (DOWN, CHANGE, etc) - Link signals - Unlink signals - Group leader signals All of the above already defined as asynchronous signals in the language. The implementation of messages signals was quite asynchronous to begin with, but had quite strict delivery constraints due to the ordering guarantees of signals between a pair of processes. The previously used message queue partitioned into two halves has been replaced by a more general signal queue partitioned into three parts that service all kinds of signals. More details regarding the signal queue can be found in comments in the erl_proc_sig_queue.h file. The monitor and link implementations have also been completely replaced in order to fit the new asynchronous signaling implementation as good as possible. More details regarding the new monitor and link implementations can be found in the erl_monitor_link.h file.
2017-11-14Fix broken receive optimizationBjörn Gustavsson
When a ref is created before performing a receive that will only receive message containing that ref, there is a compiler optimization to avoid scanning messages that can't possible contain the newly created ref. Magnus Lång pointed out that the implementation of the optimization is flawed. Exceptions or recursive calls could cause the receive operation to scan the receive queue from a position beyond the expected message (that is, the message containing the ref would never be matched out). See the receive_opt_exception/1 and receive_opt_recursion/1 test cases in receive_SUITE. It turns out that we can simplify the implementation of the optimization while fixing the bug (suggested by Magnus Lång). We actually don't need the c_p->msg.mark field. It is enough to have c_p->msg.saved_pos; if it is non-zero, it is a valid position in the message qeueue. All we need to do is to ensure that we clear c_p->msg.saved_pos when a receive is exited normally or abnormally. We can clear c_p->msg.saved_pos in JOIN_MESSAGE(), since it is called both when leaving a receive because a message matched and because there was a timeout and the 'after' clause was executed. In addition, we need to clear c_p->msg.saved_pos when an exception is caught. https://bugs.erlang.org/browse/ERL-511
2017-09-13Refactor instructions to support relative jumpsBjörn Gustavsson
Introduce new macros that can be used for relative jumps and use them consistently. Test that everything works by using a non-zero constant JUMP_OFFSET. The loader subtracts JUMP_OFFSET from loaded labels, and all instructions that use 'f' operands add it back.
2017-08-31Optimize dispatch of loop_rec from recv_setBjörn Gustavsson
We KNOW that recv_set instruction is immediately followed by a loop_rec instruction.
2017-08-31Add missing -no_next directivesBjörn Gustavsson
2017-08-11Break out most instructions from beam_emu.cBjörn Gustavsson