[LLVMdev] On-Stack Replacement & Code Patching
Joachim Durchholz
jo at durchholz.org
Wed Mar 10 23:12:34 PST 2010
(Sorry for answering to the wrong message, but there's a foulup on my
side and I don't have the original message anymore.)
I'm sceptical that what you want is even logically possible, Nyx.
Even if you just recompile f with better optimization, the call site for
g might have gone away. For example, g might have been inlined into f,
or a loop might have been unrolled and now there are a dozen call site,
or the call to g might have moved out of a loop because the compiler has
determined it's invariant (but now you need to restart the function
because the new loop code assumes the result of g is available right
from the start of the loop and now halfways through the loop body).
If you want to exchange code while the system is running, my advice
would be:
* create new versions of the functions to be replaced
* new calls run the new code, old calls complete using the old code,
garbage collect the old code when the last stack frame that uses it goes
away
* write small, short-lived functions so the turnover is quick
* break tasks that run for a long time into a loop doing short calls, so
the actual work is still done in short-lived functions
* prevent LLVM from inlining into long-lived functions
Entire million-LoC systems have been built that way. See Joe Armstrong's
PhD thesis for patterns that are useful with such a style. (I don't
agree with him that everything should be a concurrent process, but if
you replace "process" with "function" and "message send/receive" with
"subroutine call", you would get the same ability to upgrade the system
while it's running. Only the top-level loops and long-running functions
would need to be written in the everything-is-a-tight-loop pattern
that's so prevalent in the system he's describing.)
Just a suggestion that may or may not fit your situation.
Regards,
Jo
More information about the llvm-dev
mailing list