docs/ACE-subsets.html

<!-- $Id: ACE-subsets.html 80826 2008-03-04 14:51:23Z wotte $ -->

<html>
  <head>
    <title>ACE+TAO Subsetting</title>
    <link rev=made href="mailto:ace-users@cs.wustl.edu">
  </head>

<body text = "#000000"
      link="#000fff"
      vlink="#ff0f0f"
      bgcolor="#ffffff">

<hr><p>
<H2>ACE+TAO Subsetting</H2>

<p>
We are involved in ongoing activities to subset ACE+TAO to make them
more flexible and to reduce their memory footprint for embedded
systems.  This document describes what we've done thus far, what we're
planning to do next, and how to leverage our efforts to minimize the
size of your ACE+TAO applications. </P>

<hr>
<h3>Contents</h3>
<ul>
 <li><a href="#pastwork">Past Work</a>
 <li><a href="#futurework">Future Work</a>
</ul>

<hr>
<h3><a name="pastwork">Past Work</a></h3>
<p>

Previous ACE+TAO subsetting efforts were mainly concerned with
breaking up ACE into multiple libraries.  Although this was a worthy
goal, the existing component definitions in <a
href="../ace/ace.mpc">ace.mpc</a> are too tightly coupled.  Even if
ACE was compiled into multiple libraries, therefore, applications
would still have to link almost every one of them.</p>

<p>
Potentially more satisfying results can be obtained through the use of
namespaces, e.g., ACE_OS, and/or breaking up large cpp's into smaller
ones to decrease the size of object files, and statically linking them
into the application.</p>

<p>
In fact, this technique was applied systematically to ACE_OS in 2003,
and resulted in a <a
href="http://www.dre.vanderbilt.edu/Stats/footprint.shtml">10-15%
decrease in overall footprint</a> for statically linked applications.
Interestingly, these techniques also helped reduce <a
href="http://www.dre.vanderbilt.edu/~isisbuilds/auto_compile_logs/CP_Metrics/metrics/">compilation
times by ~50%</a>.</p>

<p>
Another very powerful technique for reducing the size of shared
libries is <a href="../apps/soreduce/README">The Shared Library
Reduction (<CODE>soreduce</CODE>) tool</a>.  <code>soreduce</code>
also benifits from the techniques listed above and should give
results comparable to static linking.  In fact, when deploying multiple
applications, use of shared libraries with <code>soreduce</code> will
result in smaller overall footprint than static linking.</p>

<hr>
<h3><a name="futurework">Future Work</a></h3>
<p>

Depending on funding and contributions from the ACE community, future
work on subsetting in ACE can be divided into two thrusts: <P>

<UL>

<LI> <B>Code refactoring</B>, which helps to reduce the coupling
between applications and ACE C++ wrappers and frameworks.  The amount
of coupling that's in ACE currently yields larger compiled size for
executable applications, increased link times, and indirect dependency
on a large amounts of code that may not be needed for many embedded
applications. <P>

<LI> <B>Functionality Refactoring</B>, which enables application
developers to choose lightweight reusable classes and frameworks,
rather than monolithic and heavyweight implementations, to decrease
compilation times, link times, and compiled memory footprint of
embedded applications. <P>

</UL>

Our ideas for performing each of these thrusts is described in detail
below.

<h4>ACE Code Refactoring</H4>
    
ACE is currently designed in such a way that application developers
must link many classes and methods of ACE with their application, even
if they use a small number of classes and functions in their
application.  As a result, static memory resource utilization is
unnecessarily high for common use cases.  This section describes
techniques to address the existing code structuring complexities in
ACE, which were originally driven by the poor quality of C++ tools
that were available in the 1990's.  For example, early C++ compilers
in the embedded domain lacked support for namespaces, which forced
developers to write classes that had a number of utility functions
useful for network programming.  Now that modern C++ compilers have
better support for standard C++, we propose the following
optimizations to ACE: <P>

<UL>

<LI> We will identify ACE classes and utility functions that serve a
   common goal, and move them into a namespace of their own.  Since C++
   allows a single namespace to be reopened in multiple translation
   units, we plan to split the operations into multiple C++ source
   files, giving the linker a chance to choose a smaller sized object
   files while creating an executable. <P>

<LI> Currently, ACE inlines many of its methods, which tradesoff run-time
   performance for larger footprint.  We propose to examine the contents
   of inlined files in ACE, and evaluate whether inlining is required in
   every instance.  ACE aggressively inlined functions to get better
   performance from the tool chains, but this has lead to increased code
   coupling within ACE, as well as increased coupling between
   applications that use ACE.  We will evaluate the tradeoffs associated
   with inlining and performance of certain functions and selectively
   inline those methods.  These optimizations are described further in
   <A
HREF="http://www.amazon.com/exec/obidos/tg/detail/-/0201379503/104-7731669-1857527?v=glance">Efficient
C++: Performance Programming Techniques</A> by Dov Bulka and
   David Mayhew.
</UL>
   
We expect that we will be able to reduce footprint by ~25-30% for ACE
applications, and a ~15-20% reduction in compile and link time of
applications. <P>

<H4>Functionality Refactoring</H4>

   This section proposes to address additional compile-time and memory
footprint problems that can be solved by functionality refactoring.
During the past decade, ACE has been designed and built based on many
unique requirements from users around the globe.  Though this input
enhanced the flexibility of ACE and increased the visibility of ACE,
it also led to functionality "clumping," i.e., many classes in ACE
have functionality associated with them that are not required for many
applications.  For example, the ACE_Svc_Handler serves as an event
handler for the ACE Reactor framework, serves as a handler to
implement the thread-per-connection strategies, and can be dynamically
loaded from shared libraries using the ACE Service Configurator
framework, which in turn depends on the ACE Reactor framework.  Though
all these dependencies and functionalities are required for some
applications, they yield excessive coupling and overhead for
applications (such as clients) that only want to use the ACE
Acceptor/Connector framework to connect and send messages to remote
servers. <P>

   To address the issues of tight-coupling outlined above, we propose
to refactor the code and functionality of the existing ACE frameworks
and wrapper classes to offer finer-grained components that can be
selectively included by embedded applications.  Our initial efforts
would focus on the following key ACE frameworks: 
<UL>
<LI> Logging
<LI> Service Configurator
<LI> Object Manager
<LI> Reactor
<LI> Framework Component
<LI> Thread Manager
<LI> Proactor
</UL>

We propose to apply the techniques we have mentioned above.  As a
result, we expect that we will be able to reduce footprint by another
~20-25% for certain classes of ACE applications, and a ~15-20%
reduction in compile- and link-time of applications. <P>

   Collectively, the optimizations we propose above will greatly
reduce the memory footprint and speedup the compilation and link time
for ACE-based applications. <P>

<p> Anyone interested in contributing time or funding to these efforts
should please contact <a
href="mailto:d.schmidt@vanderbilt.edu">d.schmidt@vanderbilt.edu</a>.
If you have questions about ACE and/or ACE subsetting and footprint
reduction please post these questions to the <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">ACE mailing
list</A>.</p>

<P><HR><P>
Back to the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A>
home page.<BR>
Back to <A HREF="index.html">ACE Documentation Home</A>.

<!--#include virtual="/~schmidt/cgi-sig.html" -->
</BODY>
</HTML>