| Age | Commit message (Collapse) | Author |
|---|
|
OTP-14737
* raimo/stdlib/gen_statem-cleanup:
Improve user's guide on time-outs
Clean up and optimize code and doc
|
|
OTP-14461 - New 'rand' algorithm: Xoroshiro928** also for 'crypto'
Implement a new 'rand' algorithm named 'exro928ss' and a new 'crypto' plugin for 'rand' named 'crypto_aes'.
Both are based on Xoroshiro928** which is derived from Xoroshiro1024** modified to use 58-bit words for performance reasons in the Erlang VM. Xoroshiro1024** has got the Xoroshiro1024 generator and the StarStar scrambler from the 2018 paper "Scrambled Linear Pseudorandom Number Generators" by David Blackman and Sebastiano Vigna.
This generator and scrambler combination shows no systematic weaknesses in standard statistical tests as TestU01(BigCrush) and PractRand, unlike the previously used * and + scramblers in the 'rand' module that exhibit statistical weaknesses for the lowest bits.
The 'crypto' plugin uses AES-256 as scrambler and the Xoroshiro928 as generator, which gives the same very long period and jump functions as for Xoroshiro928**, but a cryptographically secure scrambler gives absolutely no detectable statistical weaknesses regardless of how the generated numbers are used.
The speed of 'exro928ss' is only about 30-50% slower than the default fast 'rand' algorithm, but the state is roughly the double and it produces about 8 times the garbage per iteration.
The speed of 'crypto_aes' is about half (amortized) that of the default fast 'rand' algorithm which is fast and thanks to doing encryption in batches caching the result. Hence the state is much larger.
|
|
|
|
* siri/cuddle:
[logger] Skip app level test if app cannot be loaded
Terminate nodes after failed test cases in erl_distribution_SUITE
Skip performance test on build types other than 'opt'
|
|
* maint:
stdlib: Allow lists with binaries in the Format argument
|
|
* hasse/stdlib/binary_in_format/OTP-15304:
stdlib: Allow lists with binaries in the Format argument
|
|
|
|
|
|
As a consequence of some refactoring (OTP-14983, option
'chars_limit'), the Format argument of io_lib:format() no longer
accepts binaries in lists in Erlang/OTP 21.0.
Note that if Format is not of type io:format(), control sequences in
Format are ignored. This can result in unpredictable behaviour if, for
example, the output of io_lib:format() is used as Format: if the
output happens to be a string(), then control sequences are
interpreted, otherwise not.
A check that Format is of type io:format() will likely be introduced
in Erlang/OTP 22.0. That will probably mean work for some users, but
considering how unpredictable io_lib:format() is, we should try to fix
that.
|
|
|
|
|
|
Conflicts:
lib/crypto/doc/src/crypto.xml
lib/crypto/src/crypto.erl
|
|
Conflicts:
lib/crypto/src/crypto.erl
|
|
|
|
|
|
|
|
|
|
The encoding option was introduced in commit
270d909696a753af022df72a404c73f2895b4a02, to allow report callbacks to
format according to a given encoding. There was, however, no
connection between this encoding option, and the encoding of the
device to which the logger handler was writing.
Since a formatter is defined to return unicode:chardata(), and in
order to avoid mismatch with the encoding of the device, the encoding
option is now removed from the formatter. The handler itself must make
sure that it does not write illegal data to its device.
|
|
|
|
|
|
* siri/supervisor/warn-shutdown-race/ERL-724:
[supervisor] Add warning about race condition
|
|
ERL-724: "During a 'gentle' shutdown, supervisors unlink from their
children before sending shutdown signals to them. This can lead to a
race condition in supervision trees, when the timeout for gentle
shutdown of a parent supervisor expires and it kills a child
supervisor that has just unlinked from a child of its own, leaving the
child supervisor's own child still running after its supervisor is
killed."
This commit adds a warning about this in the documentation.
|
|
* maint:
Update PCRE from version 8.41 to version 8.42
|
|
* rickard/pcre-8.42/OTP-15217:
Update PCRE from version 8.41 to version 8.42
|
|
|
|
* sverker/erts/ets-memstat-false-leak/ERL-720/OTP-15278:
erts: Refactor ets FixedDeletion allocations
erts: Fix ets memstat false leak of FixedDeletion
|
|
|
|
causing erlang:memory to report too much ets memory.
|
|
It can also return errors and warnings.
|
|
* maint:
Updated OTP version
Update release notes
stdlib: Let dets:open_file() crash when given raw file name
Fix kernel_app doc logger_level default from info to notice
Change-Id: I581946ac5cec6574ed79017e2987039c1fdcf80a
|
|
uabboli/hb/stdlib/fix_dets_file_name/OTP-15253/ERL-555
stdlib: Let dets:open_file() crash when given raw file name
|
|
* maint:
Document allowed integer ops in types
stdlib: Fix specs of filename:basedir/2,2
|
|
See also https://bugs.erlang.org/browse/ERL-667.
|
|
* maint:
stdlib: Correct contracts in module io_lib_format
stdlib: Improve error handling in module io_lib
|
|
See also ERL-55 and OTP-13229.
|
|
|
|
|
|
Optimize binary match from 10% up to 70x
|
|
* maint:
Correct error behavior of is_map_key/2 in guards
|
|
Consider the following functions:
foo() -> bar(not_a_map).
bar(M) when not is_map_key(a, M) -> ok;
bar(_) -> error.
What will `foo/0` return? It depends. If the module is compiled
with the default compiler options, the return value will be
`ok`. If the module is compiled with the `inline` option,
the return value will be `error`.
The correct value is `error`, because the call to `is_map_key/2`
when the second argument is not a map should fail the entire
guard. That is the way other failing guards BIFs are handled.
For example:
foo() -> bar(not_a_tuple).
bar(T) when not element(1, T) -> ok;
bar(_) -> error.
`foo/0` always returns `error` (whether the code is inlined
or not).
This bug can be fixed by changing the classification of `is_map_key/2`
in the `erl_internal` module. It is now classified as a type test,
which is incorrect because type tests should not fail. Reclassifying
it as a plain guard BIF corrects the bug.
This correction also fixes the internal consistency check
failure which was reported in:
https://bugs.erlang.org/browse/ERL-699
|
|
|
|
The idea is to use memchr on the first lookup for
binary:match/2 and also after every match on binary:matches/2.
We only use memchr in case of matches because benchmarks
showed that using memchr even when we had false positives
could negatively affect performance.
This speeds up binary matching and binary splitting by 4x
in some cases and by 70x in other scenarios (when the last
character in the needle does not occur in the subject).
The reason to use memchr is that it is highly specialized
in most modern operating systems, often defaulting to
SIMD operations.
The implementation uses the reduction count to figure out
how many bytes should be read with memchr. We could increase
those numbers but they do not seem to make a large difference.
|
|
I did not find any legitimate use of "can not", however skipped
changing e.g RFCs archived in the source tree.
|
|
Refactor maps.erl
|
|
This only touches functions that are not further manually enhanced in
erl_bif_types. The hope is that this will allow dialyzer to discover
more issues in code using maps.
|
|
maps:new/0 is no longer a BIF
|
|
Using direct pattern matching on the map is more effient than pattern
matching on the result of maps:find/2, because it avoids allocating the
intermediate tuple.
|
|
Optimise creation of anonymous functions
|
|
Implementing it in Erlang allows taking advantage of the literal pool
optimisation, this means the function implemented in Erlang does no
allocations, while the BIF had to allocate new map each time it was
called. Benchmarks show the function is also slightly faster now.
|
|
This introduces a similar optimisation for normal funs
to what was introduced for external funs in #1725.
It is possible to allocate the fun as a literal, if it does not capture
the environment (i.e. it does not close over any variables).
Unfortunately it's not possible to do this in the compiler due to
problems with representation of such functions in the `.beam` files.
Fortunately, we can do this in the loader.
Simple evaluation shows that functions that don't capture the
enviornment consistute over 60% of all funs in the source code of
Erlang/OTP itself.
The only downside is that we lose a meningful value in the `pid` field
of the fun. The goal of this field, beyond debugging, was to be
able to identify the original node of a function. To be able to still do
this, the functions that are created in the loader are assigned the init
pid as the creator.
To solve issues with staryp, initially set the `erts_init_process_id`
to `ERTS_INVALID_PID` and skip the described optimisation if the value
is still uninitialised.
|
