| Age | Commit message (Collapse) | Author |
|---|
|
Currently (OpenBSD 6.2) the kqueu implementation on
opnebsd does not work properly for EOF conditions when
using EV_DISPATCH, so we use the EV_ONESHOT fallback there.
|
|
* rickard/signals/OTP-14589:
Fix VM probes compilation
Fix lock counting
Fix signal order for is_process_alive
Fix signal handling priority elevation
|
|
|
|
* john/erts/async-thread-defaults/OTP-14928:
Change default async thread count to 1
|
|
* john/erts/nif-map-from-array/OTP-14954:
Add enif_make_map_from_arrays
|
|
* john/erts/list-installed-nifs/OTP-14965:
Add an option to ?MODULE:module_info/1 for listing NIFs
Fix a misleading comment
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* sverker/inline-sys_memcpy:
erts: Fix some zero size sys_memcpy
|
|
|
|
Implementation of true asynchronous signaling between processes
|
|
All uses of async threads in the built-in drivers have been
replaced with dirty IO, so it no longer makes sense to leave the
default at 10.
|
|
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.
|
|
|
|
* bjorn/misc-beam-fixes:
Correctly handle get_map_elements with a literal map
core_parse: Fix handling of negative sizes in binaries
|
|
|
|
* sverker/inline-sys_memcpy:
erts: Optimize macro DMC_PUSH
erts: Make sys_memcpy and friends inline functions
|
|
to call a common static function dmc_stack_grow()
and reduce the code bloat.
and did a combined DMC_PUSH2
|
|
to avoid argument-evaluated-twice bugs
like in macro DMC_PUSH.
Had to shuffle around some #include and #define
to make erl_child_setup build debug target.
|
|
* john/erts/fix-set-owner-group/ERL-589:
Fix file:change_group/change_owner
|
|
A get_map_elements instruction that has a literal map operand
would never be translated to a i_get_map_element instruction.
That would be a problem for the following instruction:
get_map_elements Fail #{} {x,0}, {x,1}
Since the key is not a literal, get_map_element must be used,
since get_map_elements requires that a hash value can be
calculated for each element.
When the instruction is translated to i_get_map_element, the
hash value will be set to 0 and an assertion will trigger in
the debug build.
|
|
It wasn't possible to change group/owner separately, and our test
suite lacked coverage for that.
ERL-589
|
|
make erlang:process_info/1 not retrieve messages
|
|
|
|
Remove low memory need for HiPE on x86_64
|
|
* rickard/dirty-work-gone/OTP-14978:
Reschedule on ordinary scheduler if dirty work is gone
|
|
|
|
* rickard/pre-alloc-alignment/OTP-14977:
Force 64-bit alignment for pre-allocators unless x86
|
|
|
|
* rickard/remove-approx-started/OTP-14975:
Remove process start time for crash dumps
|
|
* sverker/dict-put-immed-opt:
erts: Optimize erlang:put/2 for hash collision lists
erts: Optimize erlang:put/2 for immed values
erts: Refactor erlang:put/2
|
|
|
|
|
|
|
|
* john/erts/tuple-arityval-fixes/OTP-14963/ERL-577:
Make doc entry for maximum tuple size reflect reality
Assert that sz <= MAX_ARITYVAL in make_arityval(sz)
|
|
* john/erts/assert-on-memcpy-memset-etc:
Always use sys_memcpy/cmp/etc instead of plain memcpy/cmp/etc
Check the arguments to sys_memcpy and friends
|
|
process_info/1 retrieves a number of properties related to a process,
including the list of messages in its mailbox. This is potentially
unsafe if the target process has a large number of queued messages:
- there is no a priori upper bound on the amount of memory being
allocated to hold that list, and
- the loop to retrieve the messages is uninterruptible, so the
Erlang scheduler where this executes blocks for the duration
We've seen process_info/1 bring down heavily loaded nodes on more
than one occasion. At least once it appeared to have blocked the
Erlang heart process from executing, causing the external heart to
kill the VM.
Consequently this removes 'messages' from the list of process_info
tags to retrieve for process_info/1. Note that process_info/1 still
retrieves 'message_queue_len', and process_info/2 can still retrieve
'messages' when asked to.
A few places in the OTP libraries need minor adjustments, since they
want 'message_queue_len' but compute it from the length of the list
of messages.
|
|
|
|
Passing NULL is undefined behavior and unconditionally executing these
may result in the compiler optimizing away a later NULL check. It can
often work since the pointer isn't touched when the length is 0, but
it's a major footgun. See ERL-573.
|
|
Bug introduced in commit fbb10ebc4a37555c7ea7f99e14286d862993976a
|
|
* lukas/erts/erl_child_setup_ignore_SIGTERM/OTP-14943:
erts: Ignore SIGTERM in erl_child_setup
|
|
Instead of rebuilding all cons cells before key,
just unlink key cell from list with a destructive heap write op.
This is safe as these lists never leak out and any new-to-old-heap-refs
are preserved.
|
|
No longer need for super carrier allocating executable memory.
|
|
|
