% $Id: Application.tex,v 1.38 2005/10/18 16:27:52 arvindk Exp $

\sqztiny
\section{Applying Our Specialization Too\-ls to TAO for the BasicSP Scenario}
\label{spl-to-tao}

This section presents the results of applying our specialization tools
described in Section~\ref{mw-spl-solution} to a TAO-based
implementation of the {\em BasicSP} scenario.  These results help
in quantitatively and qualitatively evaluating the extent to which
specializations improve the throughput, average- and worst-case
latency, and jitter of standard-based middleware implementations.  The
constant propagation and code refactoring techniques described in the
paper were automated using GNU {\tt autoconf} conditional compilation
techniques describ\-ed in Section~\ref{sec:resolve_5}.  The memoization,
layer-folding, and aspect weaving were automated via the FOCUS toolkit
described in Section~\ref{focus-design}.

% \sqztiny
\subsection {Analyzing General-purpose Middleware}
To specialize general-purpose Real-time CORBA middleware for PLA-based
DRE systems, we first analyzed the end-to-end critical code path of
the following synchronous two-way CORBA operation in TAO:

{\tt result = object$\rightarrow$operation (arg1, arg2)} \\

\noindent A path represents a segment of the overall end-to-end flow through the system.  The {\em critical path} is the sequence of steps that are
always necessary in TAO to process events, requests, or responses for
synchronous and asynchronous operation invocations.  This code path is
the same for processing the
\url{get_data()} two-way operation and \url{data_avail} and {\tt
timeout} events in the {\em BasicSP} scenario described in
Section~\ref{DRE-case-study}.  We use this code path to provide a
baseline for comparing our context-specific specializations to
quantify the number of steps specialized along the critical
request/\-respon\-se processing path shown by the numbered bullets in
Figure~\ref{client-server-trace}.
\begin{figure}[htpb]
\centerline{\includegraphics[width=3in]{figures/client-server-trace.eps}}
  \bfcaption{End-to-End Request Processing Path}
  \label{client-server-trace}
\end{figure}
Using this figure as a guide, we now describe the steps involved when
a client invokes a synchronous two-way operation.  After the
connection from client to server process has been established, the
following activities are performed by the TAO client ORB when a client
application thread invokes an operation on an object reference that
designates a particular target object on a TAO server
ORB:\footnote{This discussion has been generalized using the Reactor,
Acceptor-Connector, and Leader/Followers patterns~\cite{Schmidt:00a},
which are used in many popular CORBA ORBs, such as e*ORB, ORBacus,
Orbix, and TAO. }
\sqztiny
\begin{enumerate}\crunchlist
\item [1.] \url{Buffer_Manager} allocates a buffer from a memory pool. The
GIOP message parser is used to marshal the parameters in the operation
invocation.

\item [2.] Send the marshaled data to the server using the
established connection {\em e.g.}, $C_{2}$.

\item [3.] The leader thread waits on the \url{Reactor} for a reply from the
server.  The follower thread waits on a condition variable or a
semaphore.

\end{enumerate}

\sqztiny
\noindent The server ORB activities for processing a request are
described below:

\sqztiny
\begin{enumerate}\crunchlist
\item [4.] Read the header of the request arriving on connection $C_{2}$
to determine the size of the request.

\item [5.] \url{Buffer_Manager} allocate a buffer from a memory pool to
hold the request and an appropriate GIOP message parser is used to
read the request data into the buffer.

\item [6.] Demultiplex the request to locate the target portable object
a\-dap\-ter (POA)~\cite{Schmidt:98o}, servant, and skeleton -- then
dispatch the designated upcall to the servant after demarshaling the
request parameters.

\item [7.] Send the reply (if any) to the client on connection $C_{2}$.

\item [8.] Wait in the reactor's event loop for new connection and
data events.
\end{enumerate}

\sqztiny
\noindent Finally, the client ORB performs the following activities to
process a reply from the server:

\sqztiny
\begin{enumerate}\crunchlist
\item [9.] The leader thread reads the reply from the server on
connection $C_{2}$.

\item [10.]  The leader thread hands off the reply to the follower thread
by signaling the condition variable used by the follower thread.

\item [11.] The follower thread demarshals the parameters and
returns control to the client application, which processes the reply.
\end{enumerate}

% \sqztiny
\subsection{Specializing TAO Middleware}
\label{apply-spl-to-tao}

Having outlined the activities at the client and server, we now (1)
describe how we specialized TAO using invariance assumptions to
resolve the challenges for PLAs described in
Section~\ref{mw-spl-challenges} in the context of the Bold Stroke {\em
BasicSP} scenario and (2) quantitatively compare the end-to-end
latency, throughput, and predictability improvements accrued from our approach.
%For each challenge, we quantify the gains observed by applying our
%techniques.
All experiments were performed on an Intel Pentium III
851 Mhz processor with 512 MB of main memory running on Linux
2.4.7-timesys-3.1.214 kernel, which contains a very predictable
real-time kernel module.  The TAO middleware used for the experiments
was version 1.4.7, which was compiled with gcc version 3.2.2.

To ensure portability and interoperability, our specializations
larg\-ely comply with the Real-time CORBA specification and do not
modify any standard interfaces or {\em BasicSP} application code.
\iffalse
\begin{figure}[htpb]
% Arvind, does this figure add anything that's not already shown in
% Figure 2?  If not, can we remove this figure, cite figure 2 here
% instead, and add the graphs to Section 4.2.5 so it's consistent with
% the rest of the results?
\centerline {\includegraphics[width=6cm]{figures/Specialization-Summary.eps}}
  \bfcaption{Specialization Points for TAO Real-time CORBA Middleware}
  \label{fig:spl-points}
\end{figure}
\fi
%Figure~\ref{fig:spl-points} illustrates where we applied these
%specializations to the Real-time CORBA architecture.
Our specializations
resolve middleware generality challenges illustrated in
Figure~\ref{fig:basicsp-specialization}, are applied along the
critical request/\-response processing path and affect end-to-end QoS.
Our approach specializes most of the steps (1, 3, 11 on the client and
4, 6, 8 on the server).

TAO provides a wide range of configuration options (see
\url{www.dre.vanderbilt.edu/~schmidt/TAO-options.html}).
For this analysis, we used the following configuration: (1) portable
interceptors are not used, (2) servants inherit statically from
\url{org::omg::PortableServer::Servant}, {\em i.e.}, we do not
consider CORBA's dynamic invocation/skeleton features, (3) no
proprietary policies were used in the ORB, and (4) TAO's
general-purpose optimizations ({\em e.g.}, active demultiplexing,
perfect hashing, and buffer caching strategies) were enabled for all
experiments.  These assumptions are representative of ways in which
DRE systems commonly apply Real-time CORBA
middleware~\cite{Wendy:03,Sharp:03}.

To showcase our results, a sample size of 100,000 data points was used
to generate results from following types of experiments for each
specialization presented in Sections~\ref{sec:resolve_1}
through~\ref{sec:resolve_5}:
\sqzlarge
\begin{enumerate}\crunchlist
\item {\bf End-to-end latency metrics}, which measure the differences
in end-to-end latency/throughput between general-purpose and
specialized versions of TAO.  For each experiment, high-resolution
timers on the client collected end-to-end measurement data used for
analysis.

\item {\bf Path specialization metrics}, which compare latency
measures for specialized vs. general-purpose critical paths.
% Arvind, didn't you already define what a critical path was earlier?
% If this earlier definition is incomplete please update it with the
% following info.
% A path represents a segment of the overall end-to-end flow through the
% system.
%%%
% Arvind: I have added this definition to the critical path definition
% in the paper.
%%%
For each experiment, high-resolution timers within TAO's ORB core
measured latency improvements for the code path specialized within
TAO.

\item {\bf Cumulative metrics}, which measure the end-to-end latency
and predictability improvements accrued by applying all
specializations.
\end{enumerate}

\noindent For each specialization, we describe (1) the steps specialized
along the request/\-response processing path, (2) how the
specialization was automated, and (3) consequences of applying our
specialization in terms of CORBA compliance and applicability.  For
our experiments, we define {\em predictability}
as the measure of standard deviation of the data points.

% \sqztiny
\subsubsection {Applying the Aspect Weaving Specialization}
\label{res:resolve_1}
This specialization corresponds to step 3 and 9 in the client side and
step 8 in the server side of Figure~\ref{client-server-trace}.

\sqzlarge
\paragraph* {\bf Specialization automation}
Specializing the Reactor component involved (1) replacing the
\url{ACE_Reactor_Impl} class with the concrete
\url{ACE_Select_Reactor} implementation within the reactor, (2)
replacing the creation of other reactors with the specialized version
in ORB factory methods~\cite{Vlissides:94}, and (3) eliminating
virtual methods from the reactor and interfaces within the middleware.
To automate the specialization, we used FSL to capture the
transformations, some of which are shown in
Listing~\ref{reactor-spl-rules}.
\begin{Box}
\caption{\footnotesize{Reactor Specialization}}
\label{reactor-spl-rules}
\begin{Verbatim}[frame=none,fontsize=\mysize]
1: <module name="ace">
2:  <file name="Reactor.h">
3:    <remove>virtual</remove>
4:    <substitute>
5:      <search>ACE_Reactor_Impl</search>
6:      <replace>ACE_Select_Reactor</replace>
7:    </substitute>
8:  </file>
9: </module>
10: <module="TAO/tao">
11:  <file name="advanced_resource.cpp">
12:   <comment>
13:    <start-hook>TAO_REACTOR_SPL_COMMENT_HOOK_START</start-hook>
14:    <end-hook>TAO_REACTOR_SPL_COMMENT_HOOK_END</end-hook>
15:   </comment>
16:  </file>
17: </module>
\end{Verbatim}
\end{Box}
Lines 1--2 capture the module (directory or package) and file on which
the transformations are done. Devirtualizing interfaces of the reactor
is captured in line 3. Lines 4--8 allow replacing the
\url{ACE_Reactor_Impl} with the desired concrete select reactor.
Similarly, lines 12--15 show how unspecialized code within two points
in the file ($<$start-hook$>$ ... $<$end-hook$>$) is commented out for
the transformations.

Listing~\ref{annotated-source} shows how we annotate the middleware
source code with hooks based on the FSL specialization file
(Listing~\ref{reactor-spl-rules}).
\begin{Box}
\caption{\footnotesize{Annotated Middleware Source Code}}
\label{annotated-source}
\begin{Verbatim}[frame=none,fontsize=\mysize]
//File: advanced_resource.cpp
ACE_Reactor_Impl*
TAO_Default_Resource_Factory::
  allocate_reactor_impl (void) const
{
  ACE_Reactor_Impl *impl = 0;
  /* FOCUS: Comment hook */
//@@ TAO_REACTOR_SPL_COMMENT_HOOK_START
  ACE_NEW_RETURN (impl, ACE_TP_Reactor, 0);
//@@ TAO_REACTOR_SPL_COMMENT_HOOK_END
  return impl;
}
\end{Verbatim}
\end{Box}

Listing~\ref{reactor-spl-transformation} illustrates how FOCUS
transformed source code so that the base Reactor
(\url{ACE_Reactor_Impl}) is replaced with the specialized Reactor
(\url{ACE_Select_Reactor}).  This specialization is validated by our
invariance assumption that after \url{ACE_Select_Reactor} is selected,
it does not change for the {\em BasicSP} scenario.  Another
observation is that the annotations are preserved during the
transformation process, which enables multiple specializations to use
the same hook for specifying transformations, thus avoiding cluttering
of hooks within the middleware source code.

To specialize TAO's pluggable protocol implementation, we used
$<$copy-from-source$>$ capabilities provided by FSL.
\begin{Box}
\caption{\footnotesize{Transformed Middleware Source Code}}
\label{reactor-spl-transformation}
\begin{Verbatim}[frame=none,fontsize=\mysize]
//File: Reactor.h
class Reactor
{
public:
  int
   run_reactor_event_loop (REACTOR_EVENT_HOOK = 0);
  // Other public methods ....
private:
// Code woven by FOCUS:
  ACE_Select_Reactor *reactor_impl_;
// End Code woven by FOCUS
};

// File: advanced_resource.cpp
// Code woven by FOCUS:
ACE_Select_Reactor*
// End Code woven by FOCUS
TAO_Default_Resource_Factory::
  allocate_reactor_impl (void) const
{
// Code woven by FOCUS:
  ACE_Select_Reactor *impl = 0;
// End Code woven by FOCUS
  /* FOCUS: Comment hook */
//@@ TAO_REACTOR_SPL_COMMENT_HOOK_START
//  ACE_NEW_RETURN (impl, ACE_TP_Reactor, 0);
//@@ TAO_REACTOR_SPL_COMMENT_HOOK_END
// Code woven by FOCUS:
}
\end{Verbatim}
\end{Box}
Listing~\ref{protocol-spl-listing} shows how the concrete protocol
specific implementations of template methods defined in the
\url{Profile} class are copied from the \url{IIOP_Profile} class.
\begin{Box}
\caption{\footnotesize{Protocol Specialization}}
\label{protocol-spl-listing}
\begin{Verbatim}[frame=none,fontsize=\mysize]
 <file name="Profile.cpp">
  <copy-from-source>
   <source>IIOP_Profile.cpp</source>
    <copy-hook-start>PROFILE_METHODS_COPY_HOOK</copy-hook-start>
    <copy-hook-end>PROFILE_METHODS_COPY_HOOK_END</copy-hook-end>
    <dest-hook>PROFILE_SPL_ADD_HOOK</dest-hook>
  </copy-from-source>
 </file>
\end{Verbatim}
\end{Box}
As shown in the listing, $<$copy-hook-start$>$ $<$copy-hook-end$>$
tags signify the start and end locations of the template method
implementations in the \url{IIOP_Profile} class.  These concrete
implementations are copied on to the base \url{Profile} class at a
location defined within the {\tt Profile.cpp} file.  The advantage of
this design is that changes made to the implementations of the
template methods in \url{IIOP_Profile.cpp} do not necessitate a change
to the specialization file.  In fact, after we completed this
specialization, support of IPv6 protocol was added to TAO, but our
specializations required no changes.

\sqzlarge
\paragraph* {\bf Empirical results}
\begin{figure}[htpb]
  \centerline{\includegraphics[width=7cm]{figures/Reactor-spl-results.eps}}
  \bfcaption{Results for Reactor \& Protocol Specializations}
  \label{fig:reactor-spl-results}
\end{figure}
Figure~\ref{fig:reactor-spl-results} illustrates the improvements to
end-to-end latency by specializing two object-oriented frameworks used
in TAO.  Since reactors and protocols are used by both client and
server ORB, we present the most representative end-to-end results.
Our specialization results in average latency improvements of
$\sim$8$\mu$s\-e\-cs (4\%) for the reactor case and in $\sim$10$\mu$sec
(5\%) for the protocol case.  These specializations also minimize
dispersion measures for both the specializations, though not
appreciably.  The 99\% and worst-case measure also decrease, thereby
showing how removing virtual method indirection enhances
predictability.

Our results show how minimizing dynamic dispatch along the critical
path can improve performance.  Similar approaches can be applied to
specialize other frameworks used within middleware.  Based on the
results obtained in this case study, our future work will specialize
other object-oriented frameworks in TAO to further improve its
performance.

\sqzlarge
\paragraph* {\bf Applicability and CORBA compliance}
Specialization of object-oriented framework extensibility can be
applied to all ORB implementations that use virtual methods, yet can
be customized via a single concrete instance late in the system
lifecycle, {\em e.g.}, during deployment or initialization.  This
specialization is CORBA-compliant since the reactor is part of TAO's
ORB core implementation, not part of the public API defined by the
Real-time CORBA specification.  Similarly the specialization of the
protocol framework does not modify any standard APIs or application
code, but only affects hook methods specific to TAO's implementation.

% \sqztiny
\subsubsection {Applying the Memoization Specialization}
\label{res:resolve_2}
This specialization corresponds to step 1 in the client side of
Figure~\ref{client-server-trace}.

\sqzlarge
\paragraph* {\bf Specialization automation} In TAO, the GIOP engine
creates protocol specific request/\-response objects.
Listing~\ref{request-spl-listing} illustrates a portion of the
transformations for this specialization.
\begin{Box}[htbp]
\caption{\footnotesize{Specializing Request Creation}}
\label{request-spl-listing}
\begin{Verbatim}[frame=none,fontsize=\mysize]
<add>
 <hook>TAO_HEADER_CACHING_ADD_HOOK</hook>
 <data>
1.   if (__header_cached__)
2.   {
3.     // First invocation -- normal path
4.     __header_cached__ = 0;
5.     this->write_header (...);
6.     skip_length__ = this->total_length ();
7.   }
8.   else
9.   {
10.     // All invocations -- Optimized path
11.   this->skip (skip_length)
12.   }
 </data>
</add>
\end{Verbatim}
\end{Box}
During the first invocation of a request/\-response, the length of the
actual header is computed and cached (as shown in lines 1--6).  For
subsequent requests the cached pre-marshaled header is used by moving
the current writable location by the total header size.

We applied specialized request creation to TAO on a per-connect\-ion
basis, {\em i.e.}, the request headers cached are specific to a
connection.  This design stems from our invariance assumption from the
{\em BasicSP} scenario, where the \url{get_data} and
\url{data_avail} operation are sent along separate connections.

\sqzlarge
\paragraph* {\bf Empirical results}
Figure~\ref{fig:request-spl-results} illustrates the end-to-end and
code path specialization improvements that result from applying the
request creation/initialization specialization on the request and
request-specific CORBA header.  The average end-to-end latency
measures improved by $\sim$8$\mu$sec (4\%), while the path
specialization results improved by 25\%.  This discrepancy shows how
much our specialized code path influences end-to-end latency.  The
dispersion measures improve, but not significantly, by applying this
specialization.  Both 99\% and worst-case measures improve, which show
this specialization improves predictability.  These results show how
the end-to-end path specialization results are influenced by the
contribution from the actual path specialized.

\sqzlarge
\paragraph* {\bf Applicability and CORBA compliance}
Specializing the entire request is possible only if the request does
not change, which is the case for control messages sent between {\tt
Timer} and {\tt GPS} components.  Specializing the request and
request-specific header is possible if only the contents change
between requests, which is the case for the \url{get_data()}
operation.  This specialization can be applied for the standard
Real-time CORBA {\sc server\_declared} priority model, where the
priority information is set {\em a priori} during object reference
creation.  Specializing only the request header is applicable to all
requests, though it has the least payoff in terms of improvements in
performance since it represents a relatively small portion of the
request.
\begin{figure}[thpb]
  \centerline{\includegraphics[width=7cm]{figures/CORBA-Request-spl-results.eps}}
  \bfcaption{Results for Request Creation/Initialization Specialization}
  \label{fig:request-spl-results}
\end{figure}
All three approaches comply with the CORBA specification since they do
not change the type of the CORBA request message.  The third approach,
however, does not update the request identifier, which is used to
uniquely identify the client thread processing the response when
multiplexed connections are used.

% \sqzlarge
\subsubsection {Applying the Layer-Folding Specialization}
\label{res:resolve_3}
This specialization corresponds to step 6 to step 8 in the server side
of Figure~\ref{client-server-trace}.

\sqzlarge
\paragraph* {\bf Specialization automation} We implemented the
layer-folding specialization (Section~\ref{spl:invariance}) by caching
the target request dispatcher determined when the first request from
the client on a connection is serviced.  Subsequent requests used the
cached dispatcher directly, {\em i.e.}, the skeleton that services the
requests.  FSL annotations were add to TAO's POA so FOCUS can weave in
code that cached the skeleton servicing the request.  Another
annotation within the ORB core marked the start of the normal request
path.

These specialization transformations were similar to the aspect
weaving and memoization specializations discussed in
Section~\ref{spl:invariance} and are applied on a per-connection
basis.  Multiple simultaneous client connections that have different
request dispatcher can therefore be serviced concurrently.  This
design conforms to our invariance assumption from the {\em BasicSP}
scenario that the operations are same only on a per-connection basis.

\sqzlarge
\paragraph* {\bf Empirical results}
Figure~\ref{fig:dispatch-spl-results} illustrates the end-to-end and
code path performance improvements resulting from the dispatch
resolution specialization.
The average end-to-end latency measures improved by $\sim$30$\mu$secs,
which is $\sim$16\% better than the general-purpose TAO
implementation.  For the actual code path specialized this translates
to $\sim$40\% improvement in latency.  The dispersion measures for
end-to-end latencies improved by a factor of $\sim$1.5, while those
for the specialized path were twice as good as those for the
general-purpose path.  The 99\% measures are similar to the dispersion
measures, indicating improvement in predictability.  The worst-case
measures improved by 20\% when applying the dispatch resolution
specialization to the specialized path and by $\sim$14\% for the
end-to-end results.  These results show that applying layer-folding
specialization to the TAO middleware improves predictability and
latency considerably.

\begin{figure}[h]
  \centerline{\includegraphics[width=7cm]{figures/Dispatch-spl-results.eps}}
  \bfcaption{Results for Dispatch Resolution Specialization}
  \label{fig:dispatch-spl-results}
\end{figure}
\sqzlarge
\paragraph* {\bf Applicability and CORBA compliance} This
specialization applies to the \url{get_data()} operation in the {\em
BasicSP} scenario where the same operation is invoked repeatedly.
Caching the target servant and skeleton sacrifices some CORBA
compliance since thread-specific state ({\em e.g.}, CORBA Current and
POA Current are not maintained.  This context information is often
unnecessary, however, {\em e.g.}, the POA current interface is used
primarily when the POA is associated with a \url{Default_Servant}
(where one servant handles all invocations) or \url{Servant_Manager}
(which creates a servant dynamically to handle requests).  Since these
dynamic CORBA policies are rarely -- if ever -- used in DRE systems,
the impact on CORBA compliance is negligible {\em in this context}.
%Moreover, this specialization can be applied selected only when
%circumstances allow.

\subsubsection {Applying the Constant Propagation Specialization}
\label{res:resolve_4}

This specialization corresponds to steps 1 and 11 on the client and
steps 4 and 6 in the server of Figure~\ref{client-server-trace}.

\sqzlarge
\paragraph* {\bf Specialization automation}
The (de)marshaling engine within TA\-O used several OS platform-specific
capabilities that were automatically (un)set using GNU {\tt autoconf}.
GNU {\tt autoconf} necessitated the use of conditional compilation to
implement this specialization.  Two flags,
\url{CDR_IGNORE_ALIGNMENT} and \url{DISABLE_SWAP_ON_READ} were added to
the \url{write()} and \url{read()} methods within TAO's Common Data
Representation (CDR) engine to ignore alignment and byte-order values
in the request/\-response fields.  This design conforms to our
invariance assumption that the communicating entities run on
homogeneous middleware, OS, compiler, and hardware platforms, which is
often the case for production DRE systems.

\sqzlarge
\paragraph* {\bf Empirical results}
Figure~\ref{fig:demarshal-spl} illustrates the end-to-end and path
performance improvements from applying the request (de)marshali\-ng
specialization.  The specialized path for this experiment began when a
server demarshaled a request until the response was returned to the
client.  Applying the specialization that ignored alignment improved
end-to-end latencies by $\sim$8$\mu$secs (a 4\% improvement over the
general-purpose TAO implementation), while eliminating byte order
checks improved byte order checks by $\sim$9$\mu$sec (a 4\%
improvement over the general-purpose TAO implementation).  Path
specialization results improved by $\sim$ 4 -- 5$\mu$sec (a 10\%
improvement) for both the cases.  Although the general-purpose TAO
implementation performs tests on the client and server for all fields
in a CORBA request header, our specialization improvements were
relatively small since our initial experiment sent a single {\tt long}
data type, which required very few byte order tests.

\begin{figure}[ht]
  \centerline{\includegraphics[width=7cm]{figures/Demarshal-spl-results.eps}}
  \bfcaption{Results for Request (De)marshaling Specialization}
   \label{fig:demarshal-spl}
\end{figure}

To quantify the improvements from this specialization for more complex
data types, we conducted another experiment that sent an IDL structure
with four primitive types, a {\tt short}, {\tt long}, {\tt double} and
{\tt float} interspersed with a {\tt char}.  The use of a {\tt char}
type forced the general-purpose TAO middleware to re-align the
individual primitive types.  The specialized TAO middleware, however,
did not incur this overhead.

A {\tt sequence} of this structure with varying sizes was sent over
the network to measure the improvement in performance.  Both
specializations were enabled simultaneously for this experiment.
Table~\ref{demarshal-speed-up} illustrates the speed up in average
end-to-end latency accrued from applying our specialization.  The
results show that latency measures improve between 12 -- 30\% with
increasing sequence lengths.

\begin{table}[htpb]
\begin{center}
\scriptsize
\begin{tabular}{|r|r|}\hline
{\bf Sequence Length} & {\bf Speedup}
\tabularnewline \hline
 64 & 11.5\% \tabularnewline \hline
 128 & 17.35\% \tabularnewline \hline
 1,024 & 20.12\% \tabularnewline \hline
 2,048 & 25.64\% \tabularnewline \hline
 4,096 & 30.12\% \tabularnewline \hline
\end{tabular}
\caption {Performance Speedup as a Function of Sequence Length}
\label{demarshal-speed-up}
\end{center}
\vspace{-0.5cm}
\end{table}

\iffalse
that sent records of a
Library structure (IDL described in Appendix~\ref{library-example})
over the network.  The library structure consisted of a sequence of
\url{struct}s composed of basic types, structs and sequence of
\url{struct}.  The \url{stucts} where both simple (bounded length)
structures and complex (unbounded length) structures.

books each having
an ISBN (a fixed bounded struct), title (a simple struct), author
(a struct with sequences of primitive types), characters (sequence of
structs), available (a boolean) and an id (a long).  In this example
byte order tests need to be performed at multiple levels (for each
book, for each ISBN, for the number within the ISBN ....). Similarly,
padding and alignment checks need to be performed at multiple
levels, for example, padding and alignment has to be done for writing
length of name, born, dead and recommends files in the Author
structure. In the example, alignment operations are required for
each component in the book structure.
We ran the end-to-end latency measures for the library example with
both the specializations enabled.  The average end-to-end latency
measures with the specializations improved by $\sim$14\%.
\fi
These results underscore the fact that the benefits of specializations
often depend heavily on the use cases that exercise the specialized
code.

\sqzlarge
\paragraph* {\bf Applicability and CORBA compliance} Elimination
of byte-order checks and ignoring alignment specializations are
applicable to deployments on homogeneous environments {\em i.e.},
nodes with the same byte order, {\em e.g.}, {\em NodeA} and {\em
NodeB} in our {\em BasicSP} scenario, and/or the same platform
implementations at sender and receiver.  These specializations are not
CORBA compatible.  A middleware implementation, however, can add
recovery mechanisms, such as checking for byte order within the
request before using the aforementioned specializations, though these
mechanisms violate our invariance assumption.

% \sqzlarge
\subsubsection{Applying Autoconf Techniques for Platform Specialization}
\label{autoconf-spl}
This specialization corresponds to the underlying platform on which
the {\em BasicSP} scenario was run.

\sqzlarge
\paragraph* {\bf Specialization automation}
To automate the loop unrolling optimization, we used GNU {\tt
autoconf}'s
\url{AC_RUN_IFELSE} capability that compiled and executed a benchmark
to compare performance both with and without our optimization.  If our
optimization was faster, {\tt autoconf} sets the
\url{ACE_HAS_MEMCPY_LOOP_UNROLL} flag to enable the feature.
For exception support, we used GNU {\tt autoconf}'s
\url{AC_COMPILE_IFELSE} feature to determine if a compiler supported
exceptions and then empirically evaluated whether using native
exceptions was faster than emulated exceptions.

\sqzlarge
\paragraph* {\bf Empirical results}
Figure~\ref{fig:platform-spl} illustrates how applying our loop unrolling
and exception emulation specialization techniques together improved
average end-to-end latency measures by $\sim$17\%.  Worst-case latency
improved by $\sim$12\%, while the 99\% latency measures were closer to
the average for our specializations, thereby indicating better
predictability.  These results show that specializing deployment
platforms via GNU {\tt autoconf} can improve QoS significantly.

\begin{figure}[h]
\centerline{\includegraphics[width=7cm]{figures/Platform-spl.eps}}
  \bfcaption{Results for Specializing Deployment Platform}
  \label{fig:platform-spl}
\end{figure}

\sqzlarge
\paragraph* {\bf Applicability and CORBA compliance}
The GNU {\tt autoconf} specialization techniques do not affect
specification compliance at all.

% \sqztiny
\subsubsection {Applying the Specializations Cumulatively}
\label{cumulative}

Figure~\ref{fig:optimisitic-spl} illustrates the QoS improvements
accrued by applying all of the middleware specializations discussed
above to a remote CORBA operation.  The average end-to-end latency for
the specialized TAO dropped by $\sim$43\%, while the dispersion
measure was twice as good as general-purpose optimized TAO
implementation, indicating considerable improvement in predictability,
which is essential for DRE systems.

\begin{figure}[h]
\centerline{\includegraphics[width=7cm]{figures/Optimistic-Optimization.eps}}
  \bfcaption{Results for Cumulative Specialization Application}
  \label{fig:optimisitic-spl}
\end{figure}
Similarly, the 99\% bound values for the specialized TAO improved by
$\sim$40\% while worst-case measures improved by $\sim$150$\mu$se\-c\-s,
which is a 45\% improvement over the general-purpose TAO
implementation.  End-to-end throughput measures improved by
% Arvind, I assume this is an *average*, right?
%%%
% Arvind: yes.
%%%
an average of $\sim$65\%.  To measure performance speed up for a
complicated data structure, we ran the experiment using the complex
data structure from our demarshaling experiments.  For a sequence
length of 64 average latency improved by $\sim$26\%, while for a
length of 4,096 latency improved by $\sim$51\%.

\iffalse
{
\begin{table}[htpb]
\begin{center}
\scriptsize
\begin{tabular}{|c|c|}\hline
{\bf Sequence Length} & {\bf Speedup}
\tabularnewline \hline
    64 & 26\%\tabularnewline \hline
    128& 35\%\tabularnewline \hline
    1024& 39\%\tabularnewline \hline
    2048& 46\%\tabularnewline \hline
    4096& 51\%\tabularnewline \hline
\end{tabular}
\caption {Results for Cumulatively Applying Specializations to
{\tt sequence<struct>}}
\label{cumulative-table}
\end{center}
\vspace{-0.5cm}
\end{table}
} Table~\ref{cumulative-table} shows that as the sequence length
increases average end-to-end latency reduces considerably. For
example, when the sequence length is 64 average latency improves by
$\sim$26\% while for length 4,096, latency measures improve by
$\sim$51\%.

% Arvind, please revise this stuff once you've re-run the tests and
% integrated the results into the rest of the paper, as per my
% comments.
we re-ran the end-to-end latency experiments described in
Section~\ref{cumulative} with the platform specific specializations.
Our results showed that average end-to-end latency measures improved
by $\sim$43\%, throughput improved by $\sim$65\% while predictability
improvements were similar to the earlier case.  These results show
that platform-specific characteristics play a major role in
influencing QoS and middleware specializations.  Based on these
results, we are investigating other specializations, such as using
recent \url{sendfile()} optimizations in Linux to avoid data copy.
\fi

\subsection {Evaluating FOCUS}
Now that we have illustrated how FOCUS's DSL, tools, and process can
be applied to help middleware developers build and evaluate middleware
specializations, we can evaluate its benefits and drawbacks.

\sqzlarge
\paragraph*{\bf Benefits}
In resolving the challenges described in Section~\ref{challenges},
FOCUS has the following benefits:

\sqztiny
\begin{itemize}\crunchlist

\item It preserves portability of the middleware implementations it
specializes, {\em i.e.}, the specialized middleware should run on all
platforms on which the middleware runs.  The FSL snippets in
Section~\ref{res:resolve_1} do not change the interface of Reactor or
protocol components in TAO.

\item It has no external dependencies, {\em i.e.}, it does not require
external libraries to be linked for execution.

\item It supports role separation, {\em i.e.}, middleware developers
capture the specialization and annotate the middleware, whereas PLA
application developers select the specializations based on SCV
analysis.

\item It uses COTS tools and standard technologies, such as Perl
and XML, to automate the delivery of these specializations to enhance
its use in production middleware platforms.

\item Its transformations incur no unnecessary overhead at runtime since
they are performed statically at compile-time, similar to other
source-to-source transformations, such as AspectC++ ({\tt
www\-.aspec\-tc.org/}), DMS ({\tt www.sem\-designs.com}), TXL
(\url{www.txl.ca}), and Stratego-XT ({\tt
www.program-tr\-a\-nsforma\-tion.org/Stratego/}).  The transformed
middleware source code woven by FOCUS (Section~\ref{res:resolve_1})
illustrates that there is no tool-specific code inserted as a part of
the transformation process.

\item Its specializations do not affect business logic and only modify
the structure of middleware implementations, particularly
object-oriented frameworks.  The non-transformed versions of the
frameworks are therefore still available when other developers need to
use their object-oriented extensibility features.  None of the
specializations described earlier modified or specialized {\em
BasicSP} application code.
\end{itemize}

\iffalse
% Arvind, we don't need to mention this here.
Our FOCUS approach can be integrated and driven via model-driven
approaches that analyze and identify specialization opportunities from
higher level PLA system models.
\fi

\sqzlarge
\paragraph*{\bf Drawbacks}
Since FOCUS was developed primarily to help us evaluate the benefits
of middleware specializations, in general, and the TAO ORB, in
particular, it currently has the following limitations:

\sqztiny
\begin{itemize}\crunchlist

\item It automates the delivery of specializations, but not the
identification of specializations suitable for a PLA or an individual
variant.

\item Developers are responsible for ensuring that annotations are
synchronized with specialization rules, {\em i.e.}, if the annotations
are changed the specialization files also need change.  This can be
ameliorated somewhat by providing guidelines to middleware developers
and enhancing the parser to first make sure the required hooks are
present in the middleware before performing the transformations.

\item Modifications/\-enhancements to the state and/or- interface of
implementations require manual changes to the specializations, {\em
i.e.}, if the name of an operation or its parameters change, the
specialization files need to be updated.  This limitation, however, is
not specific to FOCUS but also to DMS and AspectC++.

\item The FOCUS transformation engine does not check that the woven
code executes correctly, which is a common limitation with other
source-to-source transformation tools, such as AspectC++, that rely
upon general-purpose compilers and automated quality assurance
tools to ensure the transformations compile and run properly.
\end{itemize}

\noindent Now that we have validated the benefits of automating
middleware specializations, we plan to address these limitations in
our future work on more powerful specialization languages.

\iffalse
However aspect based approaches do not provide
capabilities for eliding/refactoring code regions.  Additionally,
AspectC++ was not able to parse the TAO middleware implementation.
 provide
capabilities to implement our specialization techniques.  These
approaches provide a transformation language for capturing the
transformations and a set of tools for executing transformations
across different languages.  Transformational approaches require
middleware developers to learn the specialization language increasing
accidental complexity and force reliance on external tools.

Partial evaluation techniques such as
Tempo (\url{phoenix.labri.fr/}) for the C programming language.
transformational language (such as Stratego) for capturing the
transformations in both abstract/concrete syntax and set of
transformational tools (such as XT) for executing transformation
across different languages.  These approaches provide the
aforementioned capabilities.  have historically been applied to
compiler optimizations (such as dead code elimination), program
generation (pretty printing), and document generation.  These
approaches, however, provide specializations based on language
features (such as constant function/procedure arguments), as opposed
to feature-level invariance, which is our goal.
\fi

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \sqztiny
\subsection {Summary}

Specialization is a promising technique for alleviating the
time/\-space overhead stemming from excessive generality in
standards-based middleware implementations and improving its QoS, such
as reducing latency and jitter.  This section quantified the benefits
of specializations we applied to the TAO Real-time CORBA based on
invariants stemming from the {\em BasicSP} scenario, which itself is
based on the SCV analysis embodied in the Boeing Bold Stroke PLA.  Our
empirical results illustrate the viability of our approach to improve
the QoS of PLA-based DRE systems, where stringent performance
requirements must be met while also preserving application source code
and middleware portability/\-interoperability as much as possible.

The specialization techniques discussed in this section are targeted
to PLA developers who identify the applicability of various
specialization techniques to a variant in the PLA during SCV analysis.
Among the specializations examined and implemented in this paper,
deployment platform-specific time/\-space specializations yielded the
most improvement in QoS, followed by memoization, layer-folding, and
aspect weaving, in that order.  Our future work we will examine other
dimensions of specializations such as eliminating layering at the
client side and resolving other platform specific generality.

\iffalse
Our results also showed how
bypassing layers of middleware can improve server performance
significantly.  Our future work will examine how to eliminate layering
on the client.  Similarly, we are developing specializations to
address platform specific generality.

Object-oriented frameworks also provide opportunities for applying
aspect weaving specialization techniques to other components, such as
their concurrency frameworks, and different strategies for connection
management and purging.  Eliminating dynamic dispatching to all
components along the critical request/response path can further
improve performance.  Our future work will examine more of these
techniques.
\fi
