| Age | Commit message (Collapse) | Author |
|---|
|
Language cleaned up by the technical writers xsipewe and tmanevik
from Combitech. Proofreading and corrections by Björn Gustavsson.
|
|
|
|
* bjorn/maps:
Document the new {badmap,Term} and {badkey,Key} exceptions
Raise more descriptive error messages for failed map operations
erl_term.h: Add is_not_map() macro
Tigthen code for the i_get_map_elements/3 instruction
Pre-compute hash values for the general get_map_elements instruction
Teach the loader to pre-compute the hash value for single-key lookups
Optimize use of i_get_map_element/4
beam_emu: Slightly optimize update_map_{assoc,exact}
v3_codegen: Don't sort map keys in map creation/update
beam_validator: No longer require strict literal term order
Sort maps keys in the loader
De-optimize the has_map_fields instructions
erts/map_SUITE.erl: Add a test case that tests has_map_fields
Fully evaluate is_map/1 for literals at load-time
map_SUITE: Add tests of is_map/1 with literal maps
Run a clone of map_SUITE without optimizations
Remove the fail label operand of the new_map instruction
Correct transformation of put_map_assoc to new_map
Remove support for put_map_exact without a source map
|
|
* egil/refactor-message-queue-probes:
erts: Refactor dtrace call probes
erts: Refactor erts_queue_message
|
|
* sverk/nlmills-pr653/efile-union-pwritev/OTP-12653:
erts: Cleanup code in invoke_pwritev
Use the correct union member inside efile_drv
|
|
* sverk/crypto/rm-EVP_CIPHER_CTX_new:
crypto: Fix undefined symbol EVP_CIPHER_CTX_new
|
|
* ia/ssh/channel-gracefull-shutdown/OTP-12648:
ssh: Shutdown sftp channel gracefully
|
|
|
|
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.
|
|
* egil/fix-maps-module-exceptions/OTP-12657:
stdlib: Correct maps module exceptions upon errors
|
|
* egil/fix-maps-match_spec-return/OTP-12656:
erts: Fix building of Map result from match_specs
|
|
* peppe/common_test/report_error_if_missing_suite:
Fix problem with suite compilation failures not being correctly reported
OTP-10816
|
|
|
|
|
|
If ssh_connection:subsystem/4 fails we do not want to crash but rather
terminate gracefully.
|
|
* ia/inets/remove-ssi/OTP-12156:
inets: Remove SSI (Server Side Includes)
|
|
* hb/stdlib/fix_orddict_doc/OTP-12651:
stdlib: Correct orddict(3)
|
|
fold() and map() handle elements in a well-defined order.
Thanks to Rabbe Fogelholm for pointing out the bug.
|
|
* origin/peppe/common_test/longname_problem:
Fix error in ct_logs, not handling long names correctly
OTP-12643
|
|
Also do some minor logging improvements
|
|
For consistency with other data types, add the is_not_map() macro.
|
|
|
|
See the previous commit for justification and use cases.
|
|
Let the loader pre-compute the hash value when a single, literal key
is matched as in:
#{<<"some_key">>:=V} = Map
In my measurements, this optimization resulted in a 30 percent
speedup for short binary keys.
Unfortunately, this optimizization makes no difference for small
maps with less than 32 keys, since the hash value is not used.
Still, there are the following use cases:
* A map used instead of a record with more than 32 entries. I have
seen some applications with huge records.
* Lookup in JSON dictionaries represented as maps.
The hash value will only be used when the map is a hash map
(currently, that means at least 32 entries).
|
|
In the i_get_map_element/4 instruction, for literal keys other than
atoms, the key would be put into x[0] instead of used directly in the
instruction. The reason is that the original implementation of maps
only supported atom keys.
|
|
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.
|
|
It is no longer necessary to sort the keys, since the loader
does the sorting.
|
|
The BEAM loader will now sort keys for maps during loading, so
beam_validator should not require the keys to be ordered any order.
However, we must still ensure that literals keys are unique (which
was implicitly guaranteed by the strict ordering requirement).
|
|
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 is infrequently used. Thus there
is no need to have the fastest possible implementation; it is
better to have an implementation that reduces the code size in
the already big process_main() function.
We can transform has_map_fields to a get_map_elements instruction,
targeting the same unused x[0] register for all keys. That
instruction will only be marginally slower than existing
implementation.
|
|
The has_map_fields instruction was not tested at all by
erts/map_SUITE.erl
|
|
The compiler will only emit is_map/1 instructions with literal
argument if optimization is turned off. Therefore, the only
reason for this commit is cleanliness.
|
|
To be sure that the compiler and BEAM virtual machine correctly
handles literals maps, we must test it.
|
|
Create a clone of map_SUITE named map_no_opt_SUITE to ensure that
the loader can cope with unoptimized map instructions.
|
|
The new_map instruction cannot fail, and thus needs no fail label.
|
|
A put_map_assoc instruction with an empty source map should be
converted to a simpler new_map instruction. The transformation
didn't happen because an empty source map is no longer represented
as a NIL term (as it was in the beginning before map literals
were implemented).
|
|
Using the exact operator (':=') is only allowed when an existing map
is being updated. Thus the following causes a compilation error:
#{k:=v}
Therefore there is no need to support the put_map_exact instruction
without a source map.
|
|
Bad input to maps module function will now yield exceptions:
* {badmap,NotMap} or,
* badarg
|
|
|
|
The `invoke_pwritev()` function was in some places using the union
member intended for the `invoke_writev()` function.
|
|
|
|
* 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
|
|
* egil/fix-maps-deep-colliding-merge:
erts: Fix deep colliding hash values in maps:from_list/1
|
|
* egil/fix-hash-float-zero/OTP-12641:
erts: Ensure hashing of zero is consistent
|
|
Erlang treats positive and negative zero as equal, meaning,
true = 0.0 =:= 0.0/-1
However, Erlangs hash functions: hash, phash and phash2 did not
reflect this behaviour. Meaning, the hash values produced by
the different hash functions would not be identical for positive
and negative zero.
This commit ensures that hash value of positive zero is always
produced regardless of the signedness of the zero float, i.e.
true = erlang:phash2(0.0) =:= erlang:phash2(0.0/-1)
|
|
|
|
A faulty "box-value" entered into the heap which could cause
a segmentation fault in the garbage collector if it was written
on a heap fragment.
|
|
Conflicts:
OTP_VERSION
|
|
|
|
|
