cross-module inlining - just in time?

[Roger Larsson]

Why do all cross-module inlining at compile time?
Why not when (re)loading?

How often is code actually reloaded into a running Erlang system?
I think I have read something about genering Erlang source
from complex data (queries), compile and load while running?
Is this common?

If reloading modules are not common what about running a global
inlining/optimization pass after reloading a module. This could be
done just in time when a call is made to another module.

When a module is reloaded all such optimizations could be discarded.
(First load does not need to discard any optimizations - no one could
 yet be a user. Later with better dependency tracking is implemented
less optimizations need to be discarded).

Wouldn't just in time inlining solve:
- records
- interface functions (with data validation, send, receive)
- constant functions

Maybe there should be two types of cross-module inlining.
1. Modules compiled together with other modules - subsystem
    Contained and loaded together.
	"Parent" + "Childs" + Subsystem internal datatypes
	But for better optimization even stdlib modules like "lists"
	should be compiled in.
	Resulting .beam should be self contained (ie should not require "lists"
        when loaded)
2. Modules loaded together at runtime - system
	linked and optimized in run time (should not require the same "lists"
	implementation). Would this optimization even be necessary?

Could this be possible? Where would otp modules fit, would they need to
be separately compiled or could they be contained?

/RogerL