| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
