How code is compiled and loaded is not a language issue, but is system dependent. This chapter describes compilation and code loading in Erlang/OTP with pointers to relevant parts of the documentation.
Erlang programs must be compiled to object code.
The compiler can generate a new file which contains the object
code. The current abstract machine which runs the object code is
called BEAM, therefore the object files get the suffix
The compiler is located in the Kernel module
compile:file(Module) compile:file(Module, Options)
The Erlang shell understands the command
There is also a module
The compiler can also be accessed from the OS prompt, see
% erl -compile Module1...ModuleN % erl -make
The
% erlc <flags> File1.erl...FileN.erl
The object code must be loaded into the Erlang runtime
system. This is handled by the code server, see
The code server loads code according to a code loading strategy which is either interactive (default) or embedded. In interactive mode, code are searched for in a code path and loaded when first referenced. In embedded mode, code is loaded at start-up according to a boot script. This is described in System Principles.
Erlang supports change of code in a running system. Code replacement is done on module level.
The code of a module can exist in two variants in a system: current and old. When a module is loaded into the system for the first time, the code becomes 'current'. If then a new instance of the module is loaded, the code of the previous instance becomes 'old' and the new instance becomes 'current'.
Both old and current code is valid, and may be evaluated concurrently. Fully qualified function calls always refer to current code. Old code may still be evaluated because of processes lingering in the old code.
If a third instance of the module is loaded, the code server will remove (purge) the old code and any processes lingering in it will be terminated. Then the third instance becomes 'current' and the previously current code becomes 'old'.
To change from old code to current code, a process must make a fully qualified function call. Example:
-module(m). -export([loop/0]). loop() -> receive code_switch -> m:loop(); Msg -> ... loop() end.
To make the process change code, send the message
For code replacement of funs to work, the tuple syntax
This section describes an experimental feature that was introduced in R13B03, and changed in a backwards-incompatible way in R13B04. There may be more backward-incompatible changes in future releases.
The
-on_load(Name/0).
It is not necessary to export the function. It will be called in a
freshly spawned process (which will be terminated as soon as the function
returns). The function must return
A process that calls any function in a module whose
In embedded mode, all modules will be loaded first and then
will all on_load functions be called. The system will be
terminated unless all of the on_load functions return
Example:
-module(m). -on_load(load_my_nifs/0). load_my_nifs() -> NifPath = ..., %Set up the path to the NIF library. Info = ..., %Initialize the Info term erlang:load_nif(NifPath, Info).
If the call to