inter-process inlining

[Sven-Olof Nystr|m]

Jim Larson writes:
 > In message <Pine.GSO.4.44.0211300022230.23417-100000@REDACTED> you write:
 > >
 > >Just a thought that came to me while driving home.
 > >
 > >The EUC talk "On reducing interprocess overhead
 > >communication in concurrent programs" mentioned the idea of
 > >inlining, where a client process could (in some cases)
 > >directly fetch the server's state and perform the operation
 > >needed without context switching.
 > >
 > >Perhaps it's mentioned somewhere in the paper, but what
 > >happens if there is a bug in the server code, and it
 > >crashes?
 > 
 > The paper doesn't appear to mention it.
 > 
 > Along the same lines, some runtime mechanism would have to watch
 > for hot-loading of the server's code modules and dynamically
 > "recompile" the client's inlined code.  The paper doesn't mention
 > this explicitly, but it does propose an auxiliary process that looks
 > for optimization opportunities in the running system - this could
 > be extended to handle module replacement as well.
 > 
 > >Would the normal error indication be simulated even with
 > >inlining, or would there be an entirely different error?
 > 
 > You certainly *could* simulate the usual error behavior with inlining
 > - you just have to be careful that the costs of this fidelity don't
 > eliminate the benefits of inlining.
 > 
 > Since, presumably, the errors are rare and not performance-critical,
 > a clever implementor could make the non-error case faster at the
 > expense of needing more work to generate the correct error message.

The two authors of the paper are unlikely to reply anytime soon due to
various personal reasons. I co-authored a paper with Happi which
discussed some similar ideas (Workshop on dynamic and adaptive
compilation 2000), so perhaps I can help out.

First, regarding hot-loading. Before executing any in-lined code the
client checks that a) the server's mailbox is empty, and b) that the
server is suspended at the right program point. Testing for b is
done by checking the program counter. If the server's code has been
replaced the program counter will be different, the test will fail and
the inlined code will not be executed.

About exceptions. (I assume that crash = throw an exception. Are there
any other types of crashes that should be considered?)  This question
is trickier. As far as I know, Happi has not addressed this issue
directly. There are two issues that need to be handled. First, the
exceptions must somehow be caught, as they cannot be allowed to affect
the client process. Second, the exception must be reproduced on the
server, either immediately or when the server is scheduled.

Note that extracted code (that is, server code executed by the client)
must satisfy a number of properties, for example, it must not suspend,
and it must terminate. Second, code executed by the client must be
modified to allow external execution. In particular, special versions
of all bifs are needed. Given that we have full control over which
code is inlined and that all this code is rewritten for external
execution (using special bifs etc) it should be possible to catch all
exceptions.

Since we want optimized code to behave 'as if' the optimization hadn't
happend, we want the server code to throw the exception it would have
thrown originally. If the inlined code does not contain any
side-effects, the solution is simple: pretend that the optimization
never happend and that the inlined code was never executed. Just leave
the server in its current state, insert the message in the mailbox and
let the client continue its execution. When the server is scheduled,
it will (eventually) throw the exception. 

If the in-lined code contains side-effects things get slightly more
complicated. The simplest solution is to avoid this problem by only
inlining code that does not have side-effects (this is probably a very
reasonable restriction).

If we inline code with side effects, and code following a side-effect
throws an exception, one way of reproducing the exception is to put
the server in a state corresponding to a point in the program after
the side-effect and before the instruction causing the exception.



Hope this helps,


Sven-Olof