| Age | Commit message (Collapse) | Author |
|---|
|
by expanding the default size of the hash table
and increase number of locks.
|
|
|
|
and let compiler determine string lengths.
These were actually wrong in erl_db.c:
count_trap\0
replace_tra
select_tra
|
|
|
|
of same named table.
If other process does ets:delete
before ets:new has completely finished and done save_owned_table
then ets:delete might do delete_owned_table and deref wild pointers
in tb->common.owned.
|
|
|
|
* sverker/ets-delete_all_objects-trap/OTP-15078:
erts: Rename untrapping db_free_*empty*_table
erts: Make ets:delete_all_objects yield on fixed table
erts: Optimize ets delete all in fixed table
erts: Refactor ets select iteration code
erts: Cleanup ets code
erts: Optimize ets hash object deallocactions
erts: Refactor pseudo deleted ets objects
erts: Make atomic ets:delete_all_objects yield
erts: Fix reduction bump for ets:delete/1
|
|
* sverker/system-profile-bug/OTP-15085:
erts: Fix bug in system_profile
|
|
seen to cause redundant {profile,_,active,_,_} messages
when process is terminating.
|
|
* rickard/delete_process_schedule/OTP-15081:
Do not hold runq lock while deleting a process
|
|
|
|
Fix bug in enif_binary_to_term for immediates
|
|
‘res’ may be used uninitialized in this function
|
|
Symptom: Heap corruption
Expanded test case to provoke this bug
and test some more term types.
|
|
|
|
* 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
|
|
|
|
|
|
|
|
|
|
Bug introduced in master by
613cde66c25464121f2f6dace99782bad0e07d9b
|
|
from ensure_dirty_proc_handled
as an outline function callable from inline functions.
|
|
|
|
Symptom: maps:iterator+next returns different orders
for the exact same map.
Problem: Number of cached key-values within iterator term
depends on number of input reductions to erts_internal_map_next_3.
Solution: Build cached key-values in destructive non-reverse order
to not affect iteration order.
|
|
as it's now only used for empty tables by ets:new/2.
|
|
|
|
by only allocating one FixedDeletion with the new "all" flag
instead of one FixedDeletion per slot.
|
|
* Remove all "mtraversal_" prefixes.
* Rename all local context variables as "ctx".
* Changed callbacks from function arguments
to members of new base context struct "match_callbacks_t"
* Remove unnecessary struct initializations "= {0}"
|
|
|
|
to be done after lock has been released.
|
|
Separate pseudo-deleted-flag from the hash value.
|
|
by using a cooperative strategy that will make
any process accessing the table execute delelete_all_objects_continue
until the table is empty.
This is not an optimal solution as concurrent threads will still
block on the table lock, but at least thread progress is made.
|
|
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.
|
|
* sverker/lc-thread-exit-free-fix:
erts: Fix memory leak in lock checker at thread exit
|
|
* rickard/process_info/OTP-14966:
Fix scheduled process_info() 'status' request
Fix handling of process-info requests in receive
|
|
|
|
* 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
|
|
If no message/signal is sent (to same destination)
then monitor signal is flushed when process is scheduled out.
|
|
|
|
|
|
Leak introduced in 865ac3b740d9efa1a0583349929591c757300412.
|
|
|
|
* rickard/process_info/OTP-14966:
Restore merge of signal queues in queue_messages() if main lock is held
Fix message tracing
|
|
|
|
|
|
* '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.
|
|
fix integer truncation bugs in error logger path
|
