| Age | Commit message (Collapse) | Author |
|---|
|
|
|
done on unknown ports.
|
|
This is the result of going through all .xml files
with "clause_i" attributes and make sure
their "since" versions are correct.
|
|
This flag allows logger and other components to set the
process which log messages from ERTS are to be sent.
|
|
The ones marked since="?" are unknown (but newer than R13B03)
monitor/2
port_info/2
process_flag/2
statistics/1
system_flag/2
system_info/1
trace_pattern/3
|
|
|
|
introduced after OTP_R13B03.
|
|
to include ports and NIF resources.
Added new opaque type 'nif_resource'.
|
|
from erlang:open_port/2 docs.
|
|
Use erlang:system_info(ets_count) and improve docs
|
|
|
|
|
|
|
|
|
|
|
|
* sverker/ets-count/OTP-14987:
erts,stdlib: Improve docs about obsolete ets_limit
erts: Reduce test log noise from ets_SUITE
erts: Increase scalability of ets name lookup
erts: Rename one of delete_trap to select_delete_trap
erts: Refactor usage of am_atom_put to ERTS_MAKE_AM
erts: Add system_info(ets_count)
erts: Fix narrow race between ets:new and ets:delete
|
|
|
|
|
|
Fix typos in erlang.xml
|
|
|
|
|
|
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.
|
|
* 'map-get-bif' of git://github.com/michalmuskala/otp:
Introduce map_get guard-safe function
OTP-15037
|
|
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.
|
|
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.
|
|
|
|
make erlang:process_info/1 not retrieve messages
|
|
|
|
|
|
with link to ! operator
and clarify ugly badarg for unregistered atom argument.
|
|
Attempt to make the system_info docs easier to navigate
by grouping items of similar themes together in the documentation.
|
|
* maint-20:
Updated OTP version
Update release notes
Update version numbers
erts: Add system_flags(erts_alloc,"+M?sbct *")
erts: Add age order first fit allocator strategies
erts: Refactor erl_ao_firstfit_alloc
erts: Add migration options "acnl" and "acfml"
kernel: Add os:cmd/2 with max_size option
erts: Add more stats for mbcs_pool
erts: Fix alloc_SUITE:migration
stdlib: Make ets_SUITE memory check try again
erts: Improve carrier pool search
erts: Improve alloc_SUITE:migration
erts: Refactor carrier dealloc migration
|
|
into 'sverker/master/alloc-n-migration/ERIERL-88'
|
|
into 'sverker/maint-20/alloc-n-migration/ERIERL-88'
OTP-14915
OTP-14916
OTP-14917
OTP-14918
|
|
to change sbct limit in runtime for chosen allocator type.
With great power comes great responsibility.
|
|
|
|
|
|
The call "erlang:get_stacktrace()" is not handled explicitly. If there
are issues, they can probably be ignored since erlang:get_stacktrace/1
will be deprecated and removed.
|
|
|
|
|
|
by suppressing DOP_MONITOR_P, DOP_MONITOR_P_EXIT and DOP_DEMONITOR_P
if not supported by the remote node.
In 17e198d6ee60f7dec9abfed272cf4226aea44535
I changed the behavior of erlang:monitor
to not raise badarg for c-nodes but instead create
a monitor to only supervise the connection.
But I forgot to prevent DOP_MONITOR_P and friends from being
sent to the node that does not expect them.
Note: We test both DFLAG_DIST_MONITOR and DFLAG_DIST_MONITOR_NAME
for the node to support process monitoring. This is because
erl_interface is buggy as it sets DFLAG_DIST_MONITOR without
really supporting it.
ToDo: Should erl_interface stop setting DFLAG_DIST_MONITOR
or should we change the meaning of these flags?
|
|
|
|
Add 'used' option for binary_to_term/2
|
|
|
|
|
|
|
|
|
|
Use the "anchor" attribute to improve placement of anchors in
conjunction with the "clause_i" attribute.
|
|
|
|
|
