cross-module inlining - just in time?

Vlad Dumitrescu vlad_dumitrescu@REDACTED
Wed Apr 5 08:14:00 CEST 2006


> In both cases, the crucial points is that code from the exporting module
> winds up indissolubly tangled up with code from the importing module.
> The problem this creates is that in the present system, if module M
> is reloaded, *only* module M is affected.  The amount of work is bounded
> by some (hopefully linear) function of the size of M.  But in a system
> with cross-module inlining, a change to a 3-line module might require
> 300 MB of code from 30,000 modules to be recompiled.  (Imagine the fun
> if one of the affected modules is the recompiler...)

Unfortunately, this isn't entirely true from a practical point of view: 
changing a record definition and recompiling just one module using it is a 
sure way to make everything crash ;-)

Likewise, changing the API of some service would also require recompilation 
of all clients.

So the problem is already here, only it doesn't manifest itself at compile 
time, but at run time. I'm not sure if the one is better than the other.


More information about the erlang-questions mailing list