| Age | Commit message (Collapse) | Author |
|---|
|
epmd: allow alternative to dns resolving for nodename
|
|
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.
|
|
* rickard/suspend/OTP-14964:
Fix erts_try_lock_sig_free_proc()
Update etp
Replace previous suspend in setnode/3
New process suspend implementation based on async signaling
Teach HiPE to yield from receive
|
|
|
|
Fix typos in erl_driver.xml
|
|
|
|
Introduce is_map_key/2 guard BIF
OTP-15037
|
|
* maint:
Updated OTP version
Update release notes
Update version numbers
ssl: Prepare for release
ssl: Proper handling of clients that choose to send an empty answer to a certificate request
heart: Use ntohs instead of manual conversion
|
|
|
|
This reverts commit 202bb737e3deabfebee683266f4b7c42781eb521.
|
|
|
|
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.
|
|
* hasse/stdlib/map_guards_shell/OTP-15035/ERL-613:
erts: Correct abstract format doc regarding map creation
stdlib: Correct the linter's check of map guard expressions
|
|
* 'map-get-bif' of git://github.com/michalmuskala/otp:
Introduce map_get guard-safe function
OTP-15037
|
|
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).
|
|
* john/erts/fix-sbwt-links:
Fix seealso tags for +sbwt/+swt
|
|
|
|
christhekeele/remove-trace-terms-from-table-types-in-match-docs
Remove trace-specific terms from docs for table-oriented matchspecs
|
|
This removes the matchspec instructions `is_seq_trace` and `get_tcw/0`
from the documentation for table-oriented matchspecs.
This is likely correct as both are already documented under "Functions
Allowed Only for Tracing", despite appearing in the list of possible
options for table specs.
The following observations further back this change up:
```erl
erlang:match_spec_test([whatever], [{'_', [], [{is_seq_trace}]}], trace).
%=> {ok,true,[],[]}
erlang:match_spec_test({whatever}, [{'_', [], [{is_seq_trace}]}], table).
%=> {error,[{error,"Special form 'is_seq_trace' used in wrong %dialect."}]}
erlang:match_spec_test([whatever], [{'_', [], [{get_tcw}]}], trace).
%=> {ok,true,[],[]}
erlang:match_spec_test({whatever}, [{'_', [], [{get_tcw}]}], table).
%=> {error,[{error,"Function get_tcw/0 cannot be called in this context."}]}
```
|
|
All functions, datatype and h3 headings have gotten a hover
attribute that shows a link directly to the edit page on
github for easy editing of documentation.
The github link links to the maint branch. An early attempt
was done to use the SHA of the current branch, but that did
not work well as github can only take pull requests from
branches.
|
|
In order to get line numbers into the ghlink we have to add a post
processing step for all xml files.
|
|
|
|
|
|
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.
|
|
* john/erts/async-thread-defaults/OTP-14928:
Change default async thread count to 1
|
|
|
|
|
|
to conform with erl_nif.h
|
|
|
|
|
|
|
|
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.
|
|
make erlang:process_info/1 not retrieve messages
|
|
Fix typos in erl_nif.xml
|
|
I was running this code in shell and expected it to take default `self()` meta tracer,
and start tracing `erlang:put/2`.
```
F = fun F() -> timer:sleep(5000), erlang:get(unique_field), erlang:put(unique_field, 123), F() end.
erlang:trace_pattern({erlang, put, 2}, [{['$1', '_'], [{'==', '$1', unique_field}], []}], [global]).
erlang:trace_pattern({erlang, get, 1}, [{['_'], [], [{trace, [], [call, timestamp]}]}], [meta]).
Pid = spawn(F).
```
But tracing didn't start:
```
6> flush().
Shell got {trace_ts,<0.70.0>,call,
{erlang,get,[unique_field]},
{1521,118606,753838}}
Shell got {trace_ts,<0.70.0>,call,
{erlang,get,[unique_field]},
{1521,118611,754798}}
Shell got {trace_ts,<0.70.0>,call,
{erlang,get,[unique_field]},
{1521,118616,755705}}
ok
7> erlang:trace_info(Pid, flags).
{flags,[]}
```
Turns out that I had false expectations, that `{trace, _, _}` would enable tracing on that process, inheriting meta tracer process as consumer of trace messages.
Instead it tried to take tracer from executing process (which is pointed out in docs). But there was none, so no tracing was started and flags were simply ignored (which is not that obvious from docs).
Updated docs to point out that there are cases when flags would be simply ignored, and no tracing would start.
|
|
Conflicts:
OTP_VERSION
|
|
Remove low memory need for HiPE on x86_64
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
with link to ! operator
and clarify ugly badarg for unregistered atom argument.
|
|
to replace DFLAGS_STRICT_ORDER_DELIVERY
and remove that compile time dependency.
|
|
Attempt to make the system_info docs easier to navigate
by grouping items of similar themes together in the documentation.
|
