| Age | Commit message (Collapse) | Author |
|---|
|
Commit ed06dd12ea74018b902a2c4c7924313d23cedb75 made pre-loaded
modules (such as erlang) sticky, and also made it impossible to
unstick them to prevent them from ever be reloaded.
It turns out that there are tools that may want to instrument
the erlang module (such as concuerror), so making it
impossible to unstick modules is harsh. Therefore, revert the
part of the commit that prevented unsticking the pre-loaded
modules.
|
|
Modules in the kernel, stdlib, and compiler applications are by
default "sticky", meaning that the code server will refuse to
re-load them.
The pre-loaded modules (those that are part of the run-time system
itself, such as 'erlang') are, however, not sticky. They used to be
sticky a long time ago when the pre-loaded modules were part of
the kernel application. Now they are part of the erts application.
Since re-loading a pre-loaded module can be catastrophic (especially
re-loading the 'erlang' module), the pre-loaded modules must be
sticky. Furthermore, it should not be allowed to unstick them.
The sticky_dir/1 test case in code_SUITE is never actually run and
is broken. Rewrite it.
|
|
The following sequence will NOT leave the code path unchanged:
code:add_path("/some/app/"),
.
.
.
code:del_path("/some/app/")
The reason is that code:add_path/1 will normalize the path name
(removing the trailing slash), while code:del_path/1 does not
normalize the path before searching for it in the code path.
|
|
* rickard/garbage_collect/OTP-11388:
Parallel check_process_code when code_server purge a module
Functionality for disabling garbage collection
Use asynchronous check_process_code in code_parallel_SUITE
Execution of system tasks in context of another process
Conflicts:
bootstrap/lib/kernel/ebin/hipe_unified_loader.beam
erts/preloaded/ebin/erlang.beam
erts/preloaded/ebin/erts_internal.beam
|
|
When the code_server is about to purge a module it will now issue
asynchronous check_process_code requests to all processes at once
instead of one at a time. These check_process_code operation can
execute in parallel.
|
|
|
|
servers behaves
Rationale:
Some applications (like erlide) have code to be loaded dynamically on a
node. It may be slow to load everything upfront every time, so if the
node is in interactive mode, we would like to just append to the load
path. Currently, there is no direct way to detect if the node is running
in embedded mode or not so that we can do the right thing.
|
|
|
|
|
|
|
|
If the mtime of an escript/primary archive file changes after being
added to the code path, correctly reload the archive and update the
cache.
The existing code didn't consider that it might be a zip archive and failed:
=ERROR REPORT==== 3-Aug-2011::09:21:21 ===
File operation error: bad_central_directory. Target:
/escript_archive/module.beam. Function: get_file. Process: code_server.
Thanks David Reid and Hakan Mattson.
|
|
|
|
In "13.4 Running a function when a module is loaded" in the
Reference Manual, it is said that:
A process that calls any function in a module whose on_load
function has not yet returned will be suspended until the
on_load function has returned.
That did not work if the module was loaded using code:load_binary/3.
Instead, the callers would get an 'undef' exception.
|
|
On my Linux computer, building the entire Erlang/OTP system
with hipe disabled took about 8 minutes. With hipe enabled,
but without any native code, the build took about 23 minutes,
i.e. more than 3 times slower. (The computer has 4 cores, and
I used 'make -j6'.)
On my eight-core Mac (running 'make -j10') there was only a slight
slowdown when hipe was enabled.
The culprit is hipe_unified_loader:post_beam_load/1, which will be
called every time a module is loaded (even if the module contains no
native code). If post_beam_load/1 is called in a hipe-enabled
emulator, it will block multi-scheduling, even if no work needs to be
done. Apparently the cost for blocking multi-scheduling can vary
greatly, depending on the operating system and system load.
As a quick and conservative fix, don't call post_beam_load/1 unless
some native code has been previously loaded.
|
|
|
|
While at it, eliminate an unnecessary use of throw/catch in the
implementation of soft_purge/1.
|
|
|
|
|
|
For example, if an archive (app-vsn.ez) just contains an
app-vsn/ebin/mod.beam file, the file info for the app-vsn and
app-vsn/ebin directories are faked using the file info from the
archive file as origin. The virtual direcories can also be
listed. For short, the top directories are virtual if they does
not exist.
|
|
An on_load function is supposed to return 'true' to indicate
that the module should be loaded, and 'false' if it should be
unloaded. But returning any other term, as well as causing an
exception, will also unload the module.
Since we don't like boolean values mixed with other values,
change the expected return value as follows:
* If 'ok' is returned, the module will remain loaded and become
callable.
* If any other value is returned (or an exception is generated),
the module will be unloaded. Also, if the returned value is
not an atom, send a warning message to the error_logger
(using error_logger:warning_msg/2).
The new interpretation of the return value means that an on_load
function can now directly return the return value from
erlang:load_nif/2.
|
|
|
