| Age | Commit message (Collapse) | Author |
|---|
|
* sverk/map-merge-trap:
erts: Expand test map_SUITE:t_bif_merge_and_check
|
|
with merge of randomized maps.
|
|
|
|
Reported-by: Rory Byrne
|
|
* rickard/time-improvement/OTP-11997:
Allow execution of estone suite on pre OTP-18 systems
Add parallel time monotonicity test-case
Replace usage of erlang:now() in line-tracing
Replace erlang:now() usage in emulator suite
Replace erlang:now() usage in system suite
Misc time improvements
|
|
|
|
According to EEP-43 for maps, a 'badmap' exception should be
generated when an attempt is made to update non-map term such as:
<<>>#{a=>42}
That was not implemented in the OTP 17.
José Valim suggested that we should take the opportunity to
improve the errors coming from map operations:
http://erlang.org/pipermail/erlang-questions/2015-February/083588.html
This commit implement better errors from map operations similar
to his suggestion.
When a map update operation (Map#{...}) or a BIF that expects a map
is given a non-map term, the exception will be:
{badmap,Term}
This kind of exception is similar to the {badfun,Term} exception
from operations that expect a fun.
When a map operation requires a key that is not present in a map,
the following exception will be raised:
{badkey,Key}
José Valim suggested that the exception should be
{badkey,Key,Map}. We decided not to do that because the map
could potentially be huge and cause problems if the error
propagated through links to other processes.
For BIFs, it could be argued that the exceptions could be simply
'badmap' and 'badkey', because the bad map and bad key can be found in
the argument list for the BIF in the stack backtrace. However, for the
map update operation (Map#{...}), the bad map or bad key will not be
included in the stack backtrace, so that information must be included
in the exception reason itself. For consistency, the BIFs should raise
the same exceptions as update operation.
If more than one key is missing, it is undefined which of
keys that will be reported in the {badkey,Key} exception.
|
|
In the update loop for big maps, the E variable is restored for
each turn of the loop. It only needs to be restored if a garbage
collection has been performed.
Also add a new test case that attempts to force several garbage
collections while updating a map, to help us find bugs with
incorrect restoration of the E variable after a garbage collection.
|
|
The map instructions require that the keys in the instructions
are sorted (for flatmaps). But that is an implementation detail
that should not exposed outside of the BEAM virtual machine.
Therefore, make the sorting of the keys the responsibility of
the loader and not the compiler.
Also note that the sort order for maps with numeric keys or keys
with numeric components has changed in OTP 18. That means that
code compiled for OTP 17 that operated on maps with map keys
might not work in OTP 18 without the sorting in the loader
(although it is unlikely to be an issue in practice).
|
|
The has_map_fields instruction was not tested at all by
erts/map_SUITE.erl
|
|
To be sure that the compiler and BEAM virtual machine correctly
handles literals maps, we must test it.
|
|
* egil/maps-test-coverage:
erts: Remove code that was commented out
erts: Cover maps:values/1 for large maps
erts: Test maps:from_list/1 shrinking
|
|
|
|
Repeated keys will shrink map to a flatmap if the number of pairs drops below the limit.
|
|
Reported-by: Jesper Louis Andersen
|
|
* egil/fix-maps-tmp-heap:
erts: Test deep Maps updates
erts: Use halfword secure tmp heap
erts: Remove unused tmp heap in make_internal_hash
Conflicts:
erts/emulator/test/map_SUITE.erl
|
|
* egil/fix-maps-from_list-size:
erts: Strengthen Maps merge tests
erts: Try to test deep Maps collision
erts: Fix size bug in maps:from_list/1 BIF
|
|
|
|
|
|
Ensure maps:size/1 is correct.
|
|
|
|
* egil/fix-make_internal_hash-float:
erts: Add tests for internal_hash
erts: Fix make_internal_hash for 0.0 vs -0.0
|
|
|
|
|
|
* sverk/hamt-term2bin-bug/OTP-12585:
erts: Optimize hashmap_get
erts: Remove HAMT_SUBTAG_NODE_ARRAY
erts: Fix bug in binary_to_term for hamt when yielding
erts: Rename to flatmap_from_validated_list
|
|
Conflicts:
erts/emulator/beam/erl_map.c
erts/emulator/test/map_SUITE.erl
|
|
This will also fix a bug in term_to_binary
treating full nodes as tuples and emiting LIST_EXT for leafs.
|
|
Comparison of exact terms could cause faulty term tests.
This was caused by a faulty (too small) internal type.
Symptom:
-1 = erts_internal:cmp_term(2147483648,0). %% wrong
Correct:
1 = erts_internal:cmp_term(2147483648,0).
Reported-by: Jesper Louis Andersen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
by calling make_hash2.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The old hashing did not care which value belonged to which key,
for example:
would hash the same.
|
|
|
|
|
|
to be: 116,Arity, K1,V1,K2,V2,...,Kn,Vn
instead of: 116,Arity, K1,K2,...,Kn, V1,V2,....,Vn
We think this will be better for future internal map structures
like HAMT. Would be bad if we need to iterate twice over HAMT
in term_to_binary, one for keys and one for values.
|
|
The expression,
#{} =:= M
where M was any Map, would always result in 'true'.
This commit fixes this issue by first comparing sizes for
both terms and then checking for size zero.
|
|
Faulty test for maps update
|
|
* Add tests for maps:merge/2
* Add tests for maps:update/3
* Test more corner cases
|
|
|
