module preloading in embedded mode

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

module preloading in embedded mode

Xavier Noria
I have been tracing the boot progress of a minimal release (generated with Mix) to understand who and when preloads modules and runs on_load handlers.

The source code of application.erl and application_controller.erl seem to suggest that (-init_debug notation)

    {apply,{application,load,...}

basically loads the application resource file and stores stuff in ETS tables, but object code does not seem to be loaded (that coincides with the documentation of application:load/1, but contradicts at least two books).

I have added an on_load callback in a module that prints a trace, and that trace is shown after *all* applications have been loaded, after kernel has been started, and before stdlib is started.

I thought that meant kernel:start_boot preloaded the modules. But I have read some of the initialization of kernel and I believe the callback is *not* called when the module has been loaded into the VM, but with this ad-hoc line in the init/1 of kernel_sup:
      https://github.com/erlang/otp/blob/db58a0c04ca183de5e5436e0ae97e3f109a458fe/lib/kernel/src/kernel.erl#L224

On the other hand, I have read the source code of init.erl and looks like the thing happens when processing primLoad:

    https://github.com/erlang/otp/blob/db58a0c04ca183de5e5436e0ae97e3f109a458fe/erts/preloaded/src/init.erl#L899

which goes before all application loading in a conventional generated boot script.

So, I've come with this tentative workflow:

    * primLoad loads all object code into the BEAM. In a normal boot script that means loading all modules of all bundled applications and included applications.

    * Loading applications just processes and stores the application resource file.

    * On boot, on_load handlers do not actually run when the object code is loaded into the BEAM, but much later, when kernel_sup is initialized as part of starting the kernel application (which I guess makes sense because you want to run that code when the callback is able to execute with enough stuff bootstrapped).

My walkthrough has not been exhaustive, though. Can anyone confirm/refute that?


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: module preloading in embedded mode

Xavier Noria
Ah! Even more.

I just realized that workflow does not seem to depend on the mode.

primLoad seems to be unconditionally processed, so I believe all modules in the primLoads of whatever boot script is used are loaded into the BEAM regardless of interactive/embedded.

In a release, you eager load all modules NOT because embedded mode is on, but because the generated scripts lists them all in primLoads.

What embedded does is basically preventing the error handler from falling back to the code server, here:


That's an aha! moment for me. Because some docs imply that embedded mode means eager loading.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions