Compilation and Code Loading
View SourceHow code is compiled and loaded is not a language issue, but issystem-dependent. This section describes compilation and code loading inErlang/OTP with references to relevant parts of the documentation.
Compilation
Erlang programs must becompiled to object code. The compiler can generate anew file that contains the object code. The current abstract machine, which runsthe object code, is called BEAM, therefore the object files get the suffix.beam. The compiler can also generate a binary which can be loaded directly.
The compiler is located in the modulecompile in Compiler.
compile:file(Module)compile:file(Module,Options)The Erlang shell understands the commandc(Module), which both compiles andloadsModule.
There is also a modulemake, which provides a set of functions similar to theUNIX type Make functions, see modulemake in Tools.
The compiler can also be accessed from the OS prompt using theerl executable in ERTS.
% erl -compile Module1...ModuleN% erl -makeTheerlc program provides way to compile modules from the OSshell, see theerlc executable in ERTS. Itunderstands a number of flags that can be used to define macros, add searchpaths for include files, and more.
% erlc <flags> File1.erl...FileN.erlCode Loading
The object code must beloaded into the Erlang runtime system. This is handledby thecode server, see modulecode in Kernel.
The code server loads code according to a code loading strategy, which is eitherinteractive (default) orembedded. In interactive mode, code is searched forin acode path and loaded when first referenced. In embedded mode, code isloaded at start-up according to aboot script. This is described inSystem Principles.
Code Replacement
Erlang supports change of code in a running system. Code replacement is done onthe module level.
The code of a module can exist in two variants in a system:current andold.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 theprevious instance becomes 'old' and the new instance becomes 'current'.
Both old and current code is valid, and can be evaluated concurrently. Fullyqualified function calls always refer to current code. Old code can still beevaluated because of processes lingering in the old code.
If a third instance of the module is loaded, the code server removes (purges)the old code and any processes lingering in it is terminated. Then the thirdinstance becomes 'current' and the previously current code becomes 'old'.
To change from old code to current code, a process must make a fully qualifiedfunction call.
Example:
-module(m).-export([loop/0]).loop()->receivecode_switch->m:loop();Msg->...loop()end.To make the process change code, send the messagecode_switch to it. Theprocess then makes a fully qualified call tom:loop() and changes to currentcode. Notice thatm:loop/0 must be exported.
For code replacement of funs to work, use the syntaxfun Module:FunctionName/Arity.
Running a Function When a Module is Loaded
The-on_load() directive names a function that is to be run automatically whena module is loaded.
Its syntax is as follows:
-on_load(Name/0).It is not necessary to export the function. It is called in a freshly spawnedprocess (which terminates as soon as the function returns).
The function must returnok if the module is to become the new current codefor the module and become callable.
Returning any other value or generating an exception causes the new code to beunloaded. If the return value is not an atom, a warning error report is sent tothe error logger.
If there already is current code for the module, that code will remain currentand can be called until theon_load function has returned. If theon_loadfunction fails, the current code (if any) will remain current. If there is nocurrent code for a module, any process that makes an external call to the modulebefore theon_load function has finished will be suspended until theon_loadfunction have finished.
Change
Before Erlang/OTP 19, if theon_load function failed, any previously currentcode would become old, essentially leaving the system without any working andreachable instance of the module.
In embedded mode, first all modules are loaded. Then allon_load functions arecalled. The system is terminated unless all of theon_load functions returnok.
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 termerlang:load_nif(NifPath,Info).If the call toerlang:load_nif/2 fails, the module is unloaded and a warningreport is sent to the error loader.