| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| | |
This merge commit contains additional jit implementation
for the hashmap collision nodes in
beam/jit/x86/instr_map.cpp
beam/jit/arm/instr_map.cpp
|
| | |\
| | |
| | |
| | | |
sverker/25/erts/hashmap-collision-nodes
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Restrict depth of hashmap tree to 8 levels.
Instead of rehashing with salt, give up and put colliding keys
in "collision nodes" at the bottom of the tree.
Collision nodes are normal tuples of arity 2 or larger.
The elements of collision nodes are key-value cons cells
like the other nodes, but they are sorted in map-key order.
We do linear search in them, but that's ok as they should
be small and rare in practice.
Why?
We had some scary encounter with forever colliding term pairs
in make_internal_hash(). Even though that has been fixed
we will sleep better at night knowing the hashmaps may
not recurse forever draining all memory of the machine.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Introduce a local external term format with an unspecified encoding. This
external term format is used for supporting the 'local' option of
term_to_binary/2 and term_to_iovec/2. Terms encoded on this format is only
to be decoded by the same runtime system instance that encoded it.
|
| | | |
| | |
| | |
| | |
| | | |
That is, the default 'minor_version' option is changed from 1 to 2
for term_to_binary and term_to_iovec.
|
| | | | |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The internal ordering of flatmap keys are changed to let
atoms be ordered according to atom index. This improves
lookup of smalll maps with atom keys as it avoids memory access
of the atom table entries.
This internal flatmap key order is implemented by new function
erts_cmp_flatmap_keys(). Only top level atoms are affected by the new order.
The ordering of other term types is unchanged. The two documented
term orders are of course also unchanged; arithmetic and "map-key" order.
This commit:
* Add and use erts_cmp_flatmap_keys().
* Adjust term_to_binary(_, [deterministic]) for flatmaps.
* Reimplement flatmap comparison (Map1 < Map2) to be correct,
but more complex and expensive as it cannot rely on atoms to be
"map-key" ordered.
* Remove erts_map_from_sorted_ks_and_vs() and replace all uses with
erts_map_from_ks_and_vs() as we cannot assume atom keys sort order
in compile time.
ToDo:
* Optimize erts_cmp_compound() to not be recursive on C stack for flatmaps.
It's unusual with deep maps-in-maps (I guess) but we have limited C stack
and should avoid possibilities for Erlang code to exhaust it.
* Comment and explain the flatmap comparison algorithm.
Upcoming PR-6718 will add features to
* print maps sorted (~k).
* iterate over maps in a ordered way.
Credit to José Valim <jose.valim@dashbit.co>
for the initial idea, commit and benchmarks in
https://github.com/erlang/otp/pull/6151.
|
| |/ / / |
|
| |\ \ \
| |/ / |
|
| | |\ \ |
|
| | | |\ \
| | | | |
| | | | |
| | | | | |
into sverker/25/erts/decode-unsorted-smallmap-in-hashmap/OTP-18343
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
"binary_to_term" of a hashmap (> 32 keys) with unsorted flatmap(s)
(<= 32 keys) as key(s) inside the hashmap.
The map term would be created but the map keys could not be found with
maps:get and friends. Other operations such as map compare and merge
could probably also give incorrect results.
This was only be a problem if the term was encoded outside the VM
by erl_interface, jinterface or otherwise, as the VM itself always
encodes flatmaps with sorted keys.
|
| |\ \ \ \ \
| |/ / / / |
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | | |
OTP-18328
|
| | | |\ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
into sverker/24/fix-binary_to_term-integer-overflow-2
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
- use unsigned type for the length n
- perform mutiplication by 2 in wider type
Fixes #6439
|
| |\ \ \ \ \ \ \
| |/ / / / / / |
|
| | |\ \ \ \ \ \
| | |/ / / / /
| | | | / / /
| | |_|/ / /
| |/| | | | |
OTP-18306
|
| | | |\ \ \ \
| | | |/ / /
| | | | | /
| | | |_|/
| | |/| | |
sverker/24/fix-binary_to_term-integer-overflow
|
| | | | |/
| | | |
| | | |
| | | | |
Co-authored-by: Sverker Eriksson <sverker@erlang.org>
|
| | | | |
| | | |
| | | |
| | | | |
warning C4333: '>>': right shift by too large amount, data loss
|
| |\ \ \ \
| | | | |
| | | | | |
Update windows configure cache
|
| | | | | | |
|
| |\ \ \ \ \
| |/ / / /
|/| / / /
| |/ / / |
|
| | |\ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
left in encode_size_struct_int().
|
| | | | | | |
|
| |/ / / / |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | | |
into sverker/25/fix-hopeful-fun-size-encoding/OTP-18104
This merge commit removes code that has to do with hopeful encoding
of export-funs and bit-strings, which is no longer supported in OTP-25.
|
| | |\ \ \
| | |/ /
| |/| |
| | | | |
into sverker/24/fix-hopeful-fun-size-encoding/OTP-18104
|
| | | | |
| | | |
| | | |
| | | | |
Size estimation was one byte short.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Sending a message on a pending connection containing both bitstring
and export fun {<<1:1>>,fun a:b/0} would either be encoded as-is or
with BOTH as fallbacks {{<<128>>,1},{a,b}}. Even if receiver only
supported one of either DFLAG_BIT_BINARIES or DFLAG_EXPORT_PTR_TAG.
For OTP this does not seem to be/been a practical problem as
erl_interface got support for both in OTP-22.0.
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | | |
The Size field of NEW_FUN_EXT could (most likely) be incorrect
when the fun was encoded toward a not yet established connection
and it contains export funs (fun M:F/0) or bitstrings (<<5:7>>)
in its environment.
|
| |\ \ \
| | | |
| | | |
| | | | |
sverker/25/hopeful-in-fun-env/OTP-18093
|
| | |\ \ \
| | |/ /
| |/| |
| | | | |
sverker/24/hopeful-in-fun-env/OTP-18093
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a pragmatic semi-solution to remove the symptom of a bug
that could cause invalid Size field in NEW_FUN_EXT encoded toward
a pending connection.
The Size field is not used for anything else than this sanitity check
so I see it safe to accept NEW_FUN_EXT from buggy senders.
erl_interface still relies on Size so I guess we have to fix the
encoding bug also, even though sending funs to erl_interface is not
that common.
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
jhogberg/john/erts/fix-parallel-monitor-signal-order
erts: Fix parallel signal optimization for monitors
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When the parallel signal optimization was enabled and signals were
sent without a known sender (e.g. a monitor-by-name firing), they
always landed in signal slot 0, which was rarely the same slot as
messages sent from the same process, breaking our signal order
guarantees.
This commit fixes that by always keeping track of the sender
regardless of how and where signal are sent.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit cleans up the size calculation phase of binary_to_term/1:
* Count sub terms in an **unsigned** 32-bit integer instead of in
an **signed** 32-bit integer to ensure that the counter wraps on
overflow. While the existing code worked on all platform we have
tested it on, signed overflow is is undefined behavior in the C
standard.
* Be paranoid and use the overflow-checking ADDTERM() macro for **all**
additions to the `term` variable.
* Reject lists and large tuples early if the rest of the binary being
decoded is obviously too short. (The same early rejection was already
done for maps.)
* Explicitly reject decoding maps with 2^31 or more elements on 64-bit
platforms (on 32-bit platforms there is already code to reject maps
with 2^30 or more elements). Decoding maps with that many elements
has never worked correctly, but would fail in random ways (because
the `term` variable would overflow and miscount the sub terms).
We considered counting sub terms in a 64-bit counter on 64-bit machines
to allow truly ginormous terms to be decoded, but decided that such terms
are probably a mistake and that it is better to reject them.
|
| |\ \ \
| |/ /
| | |
| | |
| | | |
* maint:
Update copyright year
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
erts: Optimize fun calls
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
By making local and external funs share the same structure, we can
remove a substantial amount of code from the `call_fun` family of
instructions.
As a result fun calls are now about 15% faster with the interpreter
on my machine, 10% faster with the x64 JIT on that same machine,
and 15% faster with the AArch64 JIT on my M1 Mac. The improvement
is a bit less pronounced for funs with free variables, and a bit
more for those without (including external funs).
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
One can do several optimizations (e.g., in the emit_i_is_tagged_tuple
and emit_i_is_tagged_tuple_ff instructions in the ARM JIT), if one can
assume that the word after the arity word in boxed terms is
located in allocated memory. This commit makes this assumption valid
by:
* creating a global constant for the empty tuple that is padded by one
word,
* chaining all placed that could create an empty tuple on the process
heap so they instead create pointers to the global empty tuple
constant and,
|
| |\ \ \ \
| |/ / /
|/| / /
| |/ / |
|
| | | | |
|
