[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