It seems every modern Erlang package wants to compile code at runtime and load it dynamically. A good example is the lager application that recompiles modules when the logging level changes.
For a time being, we discouraged the practice in Erlang on Xen. A tiny performance benefit of the recompiled logging function comes at the expense of the loading of multiple heavy-weight modules that comprise the compiler. We have gone lengths tryling to avoid importing the compiler at runtime. For instance, when porting ejabberd to Erlang on Xen we have refactored its logging facility not to use dynamic compilation.
There was another issue that hindered compilation of code at runtime. LING uses a different bytecode format. The LING bytecode found in .ling files is similar to the ‘true’ BEAM bytecode documented here. .beam files contain ‘generic’ version of the bytecode that requires a (complex) transformation step during code loading. Thus ‘c(module)’ typed in the Erlang on Xen shell used to return a not_a_beam error. It was still possible to load the compiled code but it required a remote call to the build service to perform .beam-to-.ling tranformation.
We decided to add the full runtime compilation/loading capability to Erlang on Xen. Now erlang:load_module() checks the magic number inside the binary and if it senses a .beam code it does the transformation automatically. This increases the startup latency somewhat. A new command line option -nobeam removes the capability and the related startup latency hit.
Tweet comments powered by Disqus