| Age | Commit message (Collapse) | Author |
|---|
|
This makes it possible to create a custom integration with a
key-value store for example. The key would then point to the
actual address. You would have to write your own epmd module
to make use of that feature.
|
|
Introduce is_map_key/2 guard BIF
OTP-15037
|
|
This complements the `map_get/2` guard BIF introduced in #1784.
Rationale.
`map_get/2` allows accessing map fields in guards, but it might be
problematic in more complex guard expressions, for example:
foo(X) when map_get(a, X) =:= 1 or is_list(X) -> ...
The `is_list/1` part of the guard could never succeed since the
`map_get/2` guard would fail the whole guard expression. In this
situation, this could be solved by using `;` instead of `or` to separate
the guards, but it is not possible in every case.
To solve this situation, this PR proposes a `is_map_key/2` guard that
allows to check if a map has key inside a guard before trying to access
that key. When combined with `is_map/1` this allows to construct a
purely boolean guard expression testing a value of a key in a map.
Implementation.
Given the use case motivating the introduction of this function, the PR
contains compiler optimisations that produce optimial code for the
following guard expression:
foo(X) when is_map(X) and is_map_key(a, X) and map_get(a, X) =:= 1 -> ok;
foo(_) -> error.
Given all three tests share the failure label, the `is_map_key/2` and
`is_map/2` tests are optimised away.
As with `map_get/2` the `is_map_key/2` BIF is allowed in match specs.
|
|
* siri/kernel/logger/OTP-13295:
Add documentation of the built-in logger handlers
Catch badarg in logger:get_format_depth/0
Add chars_limit option to logger_formatter
Don't kill logger process until all other processes are dead
Set call timeout for logger_server to infinity
Update primary bootstrap
Test cuddle for logger
Update cth_log_redirect to a logger handler
Start using logger internally in kernel and stdlib
Remove error_logger process and add logger process
Add logger
|
|
|
|
|
|
* 'map-get-bif' of git://github.com/michalmuskala/otp:
Introduce map_get guard-safe function
OTP-15037
|
|
* lukas/erts/poll-thread/OTP-14346:
erts: nif resource stop from poll-thread is a indirect call
|
|
* lukas/erts/dump_SUITE_fix:
erts: Increase file read timeout for signal_abort test
|
|
* john/erts/fix-lcnt-toggle-test:
Disregard locks that can't be toggled in lcnt_SUITE
|
|
Improve memory instrumentation
OTP-15024
OTP-14961
|
|
Rationale
Today all compound data types except for maps can be deconstructed in guards.
For tuples we have `element/2` and for lists `hd/1` and `tl/1`. Maps are
completely opaque to guards. This means matching on maps can't be
abstracted into macros, which is often done with repetitive guards. It
also means that maps have to be always selected whole from ETS tables,
even when only one field would be enough, which creates a potential
efficiency issue.
This PR introduces an `erlang:map_get/2` guard-safe function that allows
extracting a map field in guard. An alternative to this function would be
to introduce the syntax for extracting a value from a map that was planned
in the original EEP: `Map#{Key}`.
Even outside of guards, since this function is a guard-BIF it is more
efficient than using `maps:get/2` (since it does not need to set up the
stack), and more convenient from pattern matching on the map (compare:
`#{key := Value} = Map, Value` to `map_get(key, Map)`).
Performance considerations
A common concern against adding this function is the notion that "guards
have to be fast" and ideally execute in constant time. While there are
some counterexamples (`length/1`), what is more important is the fact
that adding those functions does not change in any way the time
complexity of pattern matching - it's already possible to match on map
fields today directly in patterns - adding this ability to guards will
niether slow down or speed up the execution, it will only make certain
programs more convenient to write.
This first version is very naive and does not perform any optimizations.
|
|
|
|
This commit replaces the old memory instrumentation with a new
implementation that scans carriers instead of wrapping
erts_alloc/erts_free. The old implementation could not extract
information without halting the emulator, had considerable runtime
overhead, and the memory maps it produced were noisy and lacked
critical information.
Since the new implementation walks through existing data structures
there's no longer a need to start the emulator with special flags to
get information about carrier utilization/fragmentation. Memory
fragmentation is also easier to diagnose as it's presented on a
per-carrier basis which eliminates the need to account for "holes"
between mmap segments.
To help track allocations, each allocation can now be tagged with
what it is and who allocated it at the cost of one extra word per
allocation. This is controlled on a per-allocator basis with the
+M<S>atags option, and is enabled by default for binary_alloc and
driver_alloc (which is also used by NIFs).
|
|
|
|
* lukas/erts/seq_tracer_nif/OTP-15029:
Fix seq_trace erl_tracer bug
Fix makefile mkdir warning
|
|
It is allowed to set the backtrace depth to 0, but when
an exception is catched the stacktrace will still contain
one element:
1> erlang:system_flag(backtrace_depth, 0).
8
2> catch error(badarg).
{'EXIT',{badarg,[{shell,apply_fun,3,
[{file,"shell.erl"},{line,908}]}]}}
However, when an exception is raised using `erlang:raise/3`, there
will be no elements in the stacktrace:
3> catch erlang:raise(error, badarg, [{fake,name,[arg],[]}]).
{'EXIT',{badarg,[]}}
Since the `error_handler` module uses `erlang:raise/3` to
raise an exception when an undefined function is called,
there will not be any stacktrace when calling an undefined
function:
4> catch undef_module:undef_name(some_argument).
{'EXIT',{undef,[]}}
Fix this inconsistency by changing `erlang:raise/3` so that
it always includes one element in the stacktrace:
3> catch erlang:raise(error, badarg, [{fake,name,[arg],[]}]).
{'EXIT',{badarg,[{fake,name,[arg],[]}]}}
4> catch undef_module:undef_name(some_argument).
{'EXIT',{undef,[{undef_module,undef_name,[some_argument],[]}]}}
|
|
|
|
|
|
|
|
for erts, stdlib, kernel and runtime_tools.
|
|
* rickard/process_info/OTP-14966:
New process_info() implementation using signals
|
|
Improve float_to_list(F, [{decimals,D}])
|
|
|
|
|
|
|
|
to better conform with io_lib:format("~.*f", [D,F])
|
|
Compile external fun expressions to literals
OTP-15003
|
|
* sverker/driver-taints/OTP-14960:
erts: Include foreign static linked drivers in taints
erts: Fix harmless bug in macro IS_DRIVER_VERSION_GE
erts: Remove our own NIF modules from "taints"
erts: Refactor erts_static_nif_get_nif_init
erts: Add dynamic loaded drivers to list of "taints"
|
|
detected by valgrind. We cannot compare monitor
in state MON_FREE before it's initialized.
Still not really kosher to access 'state' without lock or atomic-op.
|
|
* john/erts/bwt-wt-dirty-schedulers/OTP-14959:
Add +sbwt/+swt analogues for dirty schedulers
|
|
The expressions fun M:F/A, when all elements are literals are also
treated as a literal. Since they have consistent representation and
don't depend on the code currently loaded in the VM, this is safe.
This can provide significant performance improvements in code using such
functions extensively - a full function call to erlang:make_fun/3 is
replaced by a single move instruction and no register shuffling or
saving registers to stack is necessary. Additionally, compound data
types that contain such external functions as elements can be treated as
literals too.
The commit also changes the representation of external funs to be a
valid Erlang syntax and adds support for literal external funs to core
Erlang.
|
|
Sharing these settings for all schedulers can degrade performance,
so it makes sense to be able to configure them separately.
This also changes the default busy-wait time to "short" for both
kinds of dirty schedulers.
|
|
* 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/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
|
|
|
|
|
|
|
|
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 supplied without an enclosing list, bitstrings were returned
as-is instead of badarging.
|
|
|
|
A binary is a binary as long as its size in bits is evenly divisible
by 8, regardless of whether it has a bit offset or not.
|
|
When supplied without an enclosing list, bitstrings were silently
truncated to [] instead of badarging.
|
