| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* msantos/epmd-IPv6-node-reg2/PR-864/OTP-13364:
epmd: support IPv6 node registration
|
|
Fake merge. OTP-13384 was backported from OTP 18.
|
|
|
|
|
|
|
|
* rickard/fix-non-thr-emu:
Fix build wihtout thread support
|
|
|
|
* siri/ct_netconfc/allow-ssh-options/OTP-13338:
Allow any ssh option when starting a netconf client
|
|
|
|
* siri/appups-18.3:
Update appups in kernel, stdlib and sasl for OTP-18.3
|
|
|
|
* sverk/r16/crypto-EVP-aes_cbc/OTP-13384:
crypto: Fix undefined symbol EVP_CIPHER_CTX_new
crypto: use EVP for AES-CBC
|
|
Use a stack allocated context and EVP_CIPHER_CTX_init/cleanup
instead of dynamic EVP_CIPHER_CTX_new/free that does not exist in older
0.9.8 versions.
Cherry-pick from b23f1ff1f79
|
|
This enables the use of hardware acceleration for AES crypto
on newer Intel CPUs (AES-NI), among other platforms.
Cherry-pick from 425a34001fdd
|
|
|
|
* bjorn/compiler/modernize-tests:
Remove ?line macros
Replace use of lists:keysearch/3 with lists:keyfind/3
Eliminate use of doc and suite clauses
Replace ?t with test_server
Replace use of test_server:format/2 with io:format/2
Eliminate use of test_server:fail/0,1
Eliminate use of ?config() macro
Modernize use of timetraps
Eliminate useless helper functions
|
|
* josevalim/debugger-path/OTP-13375:
Use compile source info in debugger
|
|
* bjorn/compiler/bit-syntax/OTP-13374:
Produce warnings for binary patterns that will never match
v3_core: Include line number annotations in binary patterns
sys_core_fold: Introduce var_list/2
sys_core_fold: Optimize clause/4
|
|
* bjorn/multiple-load/OTP-13111:
code: Add functions that can load multiple modules
Refactor post_beam_load handling
Simplify and robustify code_server:all_loaded/1
Update preloaded modules
Add erl_prim_loader:get_modules/3
Add has_prepared_code_on_load/1 BIF
Allow erlang:finish_loading/1 to load more than one module
beam_load.c: Add a function to check for an on_load function
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
erts/emulator/beam/erl_alloc.types
erts/emulator/beam/erl_bif_info.c
erts/emulator/beam/erl_process.c
erts/preloaded/ebin/erts_internal.beam
|
|
|
|
|
|
|
|
|
|
Those clause are obsolete and never used by common_test.
|
|
The macro ?t is deprecated. Replace its use with 'test_server'.
|
|
There is no practial difference.
|
|
|
|
?config is ugly and not recommended. Use proplists:get_value/2
instead.
|
|
* siri/remove-overload/OTP-13184:
Remove module 'overload' from SASL
|
|
|
|
Change scheduler responsiveness to 'check_schedulers'.
|
|
|
|
Add functions to 'code' to allow loading of multiple modules
at once.
code:atomic_load(Modules) will load all modules at once, or fail
having loaded none of them. Since we cannot guarantee the atomicity if
there are modules with -on_load functions, the list of modules must
not contain any modules with an -on_load function.
Also, to make it possible to put an application into an inactive state
for as short time as possible, also add code:prepare_loading/1 and
code:finish_loading/1. They are used like this:
{ok,Prepared} = code:prepare_loading(Modules)
.
.
.
ok = code:finish_loading(Prepared)
code:ensure_modules_loaded/1 is useful as a pure optimization to
ensure that modules that will be needed soon have indeed been
loaded. It will not reload modules that have already been loaded and
it *will* accept modules that have an on_load function. Therefore, it
does not make sense to give any atomicity guarantees.
I did consider overloading the existing code:ensure_loaded/1
function, but rejected it because the return value is very
different. Having different forms of return values depending
on the types of arguments is confusing.
|
|
After loading a module without native code, it is still necessary
to call hipe_unified_loader:post_beam_load() to ensure that any
native calls to the module is done to the newly loaded module
(and not to a previous version of the module in native code).
Unfortunately, hipe_unified_loader:post_beam_load() can be slow
and most of the time it doesn't do anything because no previous
native code was loaded. Therefore, ad2962278f added a kludge using
the process dictionary to avoid calling post_beam_load() if no
native code at all has been loaded.
Remove the kludge by keeping track exactly of which modules that
have native code in the existing ets table. Also generalize
post_beam_load() to handle severals modules at once, since we
will soon need that functionality.
|
|
The main ets table kept by code_server contains several pieces
of information. Therefore, code_server:all_loaded/1 need to
filter the information in the table.
code_server:all_loaded/1 can be simplified if we use
ets:select/2. Currently, the filtering is done by filtering
away unwanted stuff ({sticky_dir,Mod} tuples). It is more
robust to filter on the stuff that we want to keep
({Mod,Path} tuples, where Mod is an atom) in case that we'll
add more auxiliary records to the table later.
|
|
|
|
When we are going to implement functions that can load many modules
at once, we don't the erl_prim_loader server to become a bottleneck.
Therefore, we need erl_prim_loader:get_modules/3 that can read many
BEAM files in parallel.
Note that we will not bother making reading from archive files
or using the inet loader efficient. That can be done later if it
turns out to be important.
|
|
|
|
The BIFs prepare_loading/2 and finish_loading/1 have been
designed to allow fast loading in parallel of many modules.
Because of the complications with on_load functions,
the initial implementation of finish_loading/1 only allowed
a single element in the list of prepared modules.
finish_loading/1 does not suspend other processes, but it must wait
for all schedulers to pass a write barrier ("thread progress"). The
time for all schedulers to pass the write barrier is highly variable,
depending on what kind of code they are executing. Therefore, allowing
finish_loading/1 to finish the loading for more than one module before
passing the write barrier could potentially be much faster than
calling finish_loading/1 multiple times.
The test case many/1 run on my computer shows that with "heavy load",
finish loading of 100 modules in parallel is almost 50 times faster
than loading them sequentially. With "light load", the gain is still
almost 10 times.
Here follows an actual sample of the output from the test case on
my computer (an 2012 iMac):
Light load
==========
Sequential: 22361 µs
Parallel: 2586 µs
Ratio: 9
Heavy load
==========
Sequential: 254512 µs
Parallel: 5246 µs
Ratio: 49
|
|
Either rely on the default 30 minutes timetrap, or set the timeout
using the supported methods in common_test.
|
|
|
