| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
When finalizing outgoing distribution messages
we transcode them into using tuple fallbacks if the
receiver does not support bitstrings and export-funs.
This can only happen if the message was first encoded toward
a pending connection when the receiver was unknown.
It's an optimistic approach optmimized for modern beam nodes,
that expect real bitstrings and funs (since <R13).
Only erl_interface/jinterface lack this support.
|
|
|
|
|
|
Break out from 'flags' into new dedicated 'connection_id'
just for simplicity.
Also changed flags to low bits
and that affected enif_binary_to_term.
|
|
|
|
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
from future nodes.
|
|
* Accept a raw data buffer instead of ErlNifBinary
* Accept option ERL_NIF_BIN2TERM_SAFE
* Return number of read bytes
|
|
|
|
|
|
by adding a dynamic heap factory.
"binary_to_term" is now a hybrid solution with both
a call to decoded_size() to calculate needed heap space
AND possible dynamic allocation of more heap space
if needed for big maps.
The heap size returned from decoded_size() is guaranteed
to be sufficient for all term heap data except for hashmap
nodes. All hashmap nodes are created at the end of dec_term()
by invoking the heap factory interface that may allocate more
heap space on process heap or in fragments.
With this commit it is no longer guaranteed that a message
is confined to only one heap fragment.
|
|
|
|
* Fix documentation on $char for unicode
* Remove duplicate declaration for erts_encode_ext_dist_header_size
|
|
Use same mechanism as term_to_binary to yield
while encoding large messages for distributed send.
|
|
|
|
* sverk/trapping-bin2term:
erts: Adjust term_to_binary reduction factors
erts: Yield after trapping term_to_binary if gc has been ordered
erts: Let term_to_binary disable gc while trapping
erts: Improve stress of binary_to_term in binary_SUITE
erts: Fix bug in binary_to_term for compressed on halfword
erts: Fix crash when binary_to_term throws badarg
erts: Trapping memcpy in binary_to_term
erts: Cleanup code for trapping binary_to_term
erts: Add erlang wrappers to binary_to_term
trapping uncompress
trapping size calculation
trapping binary_to_term/2
trapping STRING_EXT
trapping lists and tuples
trapping binary_to_term passing binary_SUITE
Parallel check_process_code when code_server purge a module
Functionality for disabling garbage collection
Use asynchronous check_process_code in code_parallel_SUITE
Execution of system tasks in context of another process
Conflicts:
erts/emulator/beam/external.c
erts/emulator/beam/sys.h
erts/emulator/test/binary_SUITE.erl
erts/preloaded/ebin/erlang.beam
erts/preloaded/ebin/erts_internal.beam
|
|
|
|
|
|
|
|
|
|
|
|
Since refc binaries are now supported in literal pools, there is no
longer any need to allow the creation of over-sized heap binaries.
|
|
|
|
This BIF's second parameter is a list of options.
Currently the only allowed option is {minor_version, Version}
where version is either 0 (default) or 1.
|
|
The compressed format is using a slighty modified variant of the extern format
(term_to_binary). To not worsen key lookup's too much, the top tuple itself
and the key element are not compressed. Table objects with only immediate
non-key elements will therefor not gain anything (but actually consume one
extra word for "alloc_size").
|
|
Alignment of trailing data in messages has been adjusted.
This in order to be able to pass data of any type as
trailing data in the future.
|
|
Store Erlang terms in 32-bit entities on the heap, expanding the
pointers to 64-bit when needed. This works because all terms are stored
on addresses in the 32-bit address range (the 32 most significant bits
of pointers to term data are always 0).
Introduce a new datatype called UWord (along with its companion SWord),
which is an integer having the exact same size as the machine word
(a void *), but might be larger than Eterm/Uint.
Store code as machine words, as the instructions are pointers to
executable code which might reside outside the 32-bit address range.
Continuation pointers are stored on the 32-bit stack and hence must
point to addresses in the low range, which means that loaded beam code
much be placed in the low 32-bit address range (but, as said earlier,
the instructions themselves are full words).
No Erlang term data can be stored on C stacks (enforced by an
earlier commit).
This version gives a prompt, but test cases still fail (and dump core).
The loader (and emulator loop) has instruction packing disabled.
The main issues has been in rewriting loader and actual virtual
machine. Subsystems (like distribution) does not work yet.
|
|
* jv/binary_to_term-opts:
document ErtsExternalDist flags and CON_ID mask
add options to binary_to_term
OTP-8367 There is new erlang:binary_to_binary/2 BIF that takes an option
list. The option safe can be used to prevent creation of
resources that are not garbage collected (such as atoms). (Thanks
to Jayson Vantuyl.)
|
|
In the ErtsExternalDist structure, the flags field holds a combination of flags
(tagged into the high bits) and the connection ID (in the low bits). This
wasn't clearing indicated anywhere. This patch adds a comment before the flags
and mask that indicates their use and relation to each other. This will help
guide people through the code and reduce the likelihood that someone will add a
flag without adjusting the mask.
|
|
term_to_binary and binary_to_term are powerful tools that can be used easily in
lieu of a custom binary network protocol. Unfortunately, carefully crafted
data can be used to exhaust the memory in an Erlang node by merely attempting
to decode binaries. This makes it unsafe to receive data from untrusted
sources.
This is possible because binary_to_term/1 will allocate new atoms and new
external function references. These data structures are not garbage collected.
This patch implements the new form of binary_to_term that takes a list of
options, and a simple option called 'safe'. If specified, this option will
cause decoding to fail with a badarg error if an atom or external function
reference would be allocated.
In the general case, it will happily decode any Erlang term other than those
containing new atoms or new external function references. However, fun, pid,
and ref data types can embed atoms. They might fail to decode if one of these
embedded atoms is new to the node. This may be an issue if encoded binaries
are transferred between nodes or persisted between invocations of Erlang.
|
|
|
