Re: Slow init:stop/0 due to purging modules

On Wed, Jul 7, 2021 at 10:06 AM Mikael Pettersson <[email protected]> wrote:
>
> On Tue, Jul 6, 2021 at 4:52 PM Frank Hunleth
> <[email protected]> wrote:
> > 1. Does it make sense for unloading all modules to take longer than
> > loading them? Just want to sanity check that unloading isn't slow by
> > design.
>
> Unloading a module is slower than loading it, since the unload needs
> to check all processes to see if any of them currently run in that
> module, if they do they get killed. The VM cannot permit the unload to
> create dangling references into the unloaded code.

Additionally, nowadays the heap needs to be scanned for references to
the literal pool in the module being purged. If a process has a
reference to a literal that will soon go away, it must be copied to
the heap of process.

> > 2. If the VM is going to exit anyway, is do_unload necessary for
> > graceful shutdown?
>
> I can't immediately see why unload would be needed in this scenario. I
> hope someone from the OTP team can enlighten us.

I also don't see any reason why the code would need to be unloaded. It
seems that it is done because the code is shared with init:restart()
and init:reboot(). At the time the code was rewritten a long time,
purging code was much faster than it is today.

Frank, I suggest that you create an issue.

/Björn

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB