inter-process inlining

[Sven-Olof Nystr|m]

Ulf Wiger writes:
(Exceptions)
 > >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.
 > 
 > If the exception is reproduced later, it must still be so
 > that the server actually acts on that very message (and
 > perhaps this isn't appropriate if other messages have come
 > in to the server during the scheduling delay, since a
 > selective receive might have resulted in a different
 > prioritization of messages then -- unlikely, but...)
 >
 > >Since we want optimized code to behave 'as if' the
 > >optimization hadn't happened, 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
 > >happened 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.
 > 
 > The most appropriate would perhaps be to schedule the server
 > immediately (see above). Doing it this way would also ensure
 > that the stack chain on the server reflects the situation
 > appropriately.

I don't think that's necessary. Consider the scenario: The client wants
to send a message to the server. Due to profiling and optimization the
client instead starts running inlined code from the server. Now, the
server code throws an exception. Since exceptions should be rare, we
do not want to invest much effort into handling this
situation. Instead, the client discards any intermediate results it
may have computed while running server code, inserts the message into
the server's mailbox, and continues running its own code. As far as I
can see the situation is indistinguishable from what we would have in
unoptimized code:

a) The client is running some code following the send.

b) The server is suspended on a receive.

c) The server's mailbox contains a message from the client.

d) Since scheduling is under software control, none of the other
   processes have been scheduled during the interval.

As far as I can see, this guarantees that the state is 'as if' the
optimization had never happened.

It could happen that some other process later sneaks in a message that
prevents the server from seeing the client's message (due to matching
receive), causing history to enter an entirely different path... But
note that the two behaviors (the server seeing a message that causes
an exception, or another message being read first) are possible in an
unoptimized Erlang implementation, depending on scheduling strategy,
so the optimization hasn't really changed anything.


 > >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).
 > 
 > Yes, it seems reasonable.

Yes, it's probably a good idea to restrict the optimization to
side-effect free code. I'm sure it's possible to handle the general
case, but it may not be worth the trouble.


 > >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.
 > 
 > Hmm...



Sven-Olof Nyström