cross-module inlining - just in time?
Tue Apr 4 17:55:01 CEST 2006
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:
- 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"
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?
More information about the erlang-questions