The data may be passed to the procedure through value
parameters, and return values obtained through reference parameters.
The caller is suspended pending the return of the callee.  However,
invocations differ from local procedure calls in several important
ways.  The first, which is particular to Eden, is the requirement of
an accompanying capability to name to the target Eject.  Therefore,
the Eject programmer is quite aware of the fact that an invocation is
not "just another procedure call".  A second difference is
performance.  Invocations will be far slower than a local procedure
call simply because there is more going on.  The Eden kernel must
local the target Eject; network traffic may be necessary if the target
Eject is not on the same machine; parameters must be packaged into a
message to be sent to the target Eject; the target Eject must
unpackage the message and call the desired procedure with the
parameter values; the target Eject must package the results into a
message to be sent to the invoking Eject; finally, the invoking Eject
must unpackage the results and return them to the calling procedure.
In light of such a performance deficit, Eject programmers may be
reluctant to structure a particular collection of Ejects in novel ways
in order to avoid the invocation overhead.

The thesis of this paper is to demonstrate that acceptable performance
for invocations can be obtained in the Eden environment by paying
close attention to the design and implementation of modules that
support remote procedure calls.  For the purposes of this thesis, the
scope will be limited to the Ejects' point of view.  The Eden kernel
will not be considered.

\section{Some Background}\label{introbck}

Eden has had a long history of improvements to its invocation
mechanism.  Previous work has concentrated on removing extraneous {\it
inter-process communication} (IPC) messages.  Particularly in Eden's
case, IPC messages are very expensive.  Eden is built on top of Unix;
therefore, each IPC message from an Eject to the Eden kernel, and vice
versa, involves at least a Unix process switch and copying the IPC
message into and out of the Unix kernel.

The first versions of Eden required 14 IPC messages to be sent per
local invocation.  A local invocation occurs when the invoking Eject
and the target Eject reside on the same physical machine.
What was 2-process kernel's role in this setup?

The 2-process Eden kernel was finally replaced by a 1-process Eden
kernel, immediately reducing the number of messages required for an
invocation by eliminating the IPC messages between the two kernel
processes.

The final reduction in IPC messages sent per invocation occurred
during the summer of 1984.  Two more IPC messages were eliminated.
One of the messages eliminated was the IPC message from the Eden
kernel to the invoking Eject that communicated the {\it invocation
handle} assigned to that particular call.  It was replaced by a scheme
where the invoking Eject was allowed to generate its own {\it local
invocation handle} to communicate with the Eden kernel, and the Eden
kernel would generate its own unique handle in order to communicate
with another Eden kernel or the target Eject.  The Eden kernel
guarantees that the reply message to an invocation will be stamped
with the invoking Eject-generated handle.  The other IPC message
eliminated was the status message from the Eden kernel to the target
Eject confirming the kernel's approval of the reply message (format,
or contents if capabilities were contained in the reply).  The more
logical scheme of notifying the invoking Eject of the failure status
of the reply, or the actual reply if the status was success, is now
being used.  The result of all these improvements is shown in figure
\ref{oldfig}.  (See section \ref{oldexp} for an explanation of figure
\ref{oldfig}.)

\section{Related Work}\label{introrel}

Nelson's thesis thoroughly examines remote procedure calls.  He
studies a number of implementations, and proposes a design for
Emmisary(?), a new RPC mechanism with excellent transparency and
exceptional performance.  To attain exceptional performance, Nelson
gives a list of "lessons" that an RPC mechanism must have.  The
lessons are summarized here for the reader:

\begin{itemize}
\end{itemize}

In designing an RPC mechanism, it is convenient to use a layer model.
However, strict adherance to the layer model often results in poor
implementations.  There is a prohibitive cost associated with highly
modular implementations that cannot be tolerated in RPC
implementations.  In proposing a solution to the asynchrony
problem, Cooper\cite{soft} advocates "soft layering".  The idea of soft
layering may be applied to any naturally layered system whose layers
must work well together.

\section{Structure of Thesis}\label{introstruct}

Chapter \ref{old} examines the deficiencies of the current Eden
invocation mechanism.  The reader is taken on a tour through the
process of initiating an invocation and receiving its reply, and
receiving a new invocation and replying to the invocation.

Chapter \ref{new} proposes restructuring the dispatcher module for
synchronous invocations (by far the most heavily used form of
communication within Eden) and breaking down the "hard layering" that
currently exists between the various layers that support invocations,
from the Eject's point of view, in order to obtain significant
performance gains.

\chapter{A Closer Look at the Eden Invocation Mechanism}\label{old}

\section{The Dispatcher -- Interface and Internals}\label{olddis}

\section{Flow of Data -- CIP, Stub, and ESCII}\label{olddat}

\section{Summary}\label{oldsum}

\chapter{An Alternative Synchronous Invocation Mechanism}\label{new}

\section{Assumptions and Limitations}\label{newass}

\section{The Dispatcher -- Interface and Internals}\label{newdis}

\section{A Word About Buffer Management}\label{newbuf}

\section{Flow of Data -- CIP, Stub, and ESCII}\label{newdat}

\section{Results and Timings}\label{newres}

\section{Summary}\label{newsum}

\chapter{Conclusions and Further Work}\label{concl}

\section{Lessons Re-learned}\label{conles}

\section{Soft Layering}\label{conlay}

\section{Modularization and Interfaces}\label{conmod}

\section{Further Work}\label{confur}

\end{document}

