ACE/docs/ACE-subsets.html

   1 <!--  -->
   2
   3 <html>
   4   <head>
   5     <title>ACE+TAO Subsetting</title>
   6     <link rev=made href="https://github.com/DOCGroup/ACE_TAO">
   7   </head>
   8
   9 <body text = "#000000"
  10       link="#000fff"
  11       vlink="#ff0f0f"
  12       bgcolor="#ffffff">
  13
  14 <hr><p>
  15 <H2>ACE+TAO Subsetting</H2>
  16
  17 <p>
  18 We are involved in ongoing activities to subset ACE+TAO to make them
  19 more flexible and to reduce their memory footprint for embedded
  20 systems.  This document describes what we've done thus far, what we're
  21 planning to do next, and how to leverage our efforts to minimize the
  22 size of your ACE+TAO applications. </P>
  23
  24 <hr>
  25 <h3>Contents</h3>
  26 <ul>
  27  <li><a href="#pastwork">Past Work</a>
  28  <li><a href="#futurework">Future Work</a>
  29 </ul>
  30
  31 <hr>
  32 <h3><a name="pastwork">Past Work</a></h3>
  33 <p>
  34
  35 Previous ACE+TAO subsetting efforts were mainly concerned with
  36 breaking up ACE into multiple libraries.  Although this was a worthy
  37 goal, the existing component definitions in <a
  38 href="../ace/ace.mpc">ace.mpc</a> are too tightly coupled.  Even if
  39 ACE was compiled into multiple libraries, therefore, applications
  40 would still have to link almost every one of them.</p>
  41
  42 <p>
  43 Potentially more satisfying results can be obtained through the use of
  44 namespaces, e.g., ACE_OS, and/or breaking up large cpp's into smaller
  45 ones to decrease the size of object files, and statically linking them
  46 into the application.</p>
  47
  48 <p>
  49 In fact, this technique was applied systematically to ACE_OS in 2003,
  50 and resulted in a 10-15%
  51 decrease in overall footprint for statically linked applications.
  52 Interestingly, these techniques also helped reduce compilation
  53 times by ~50%.</p>
  54
  55 <p>
  56 Another very powerful technique for reducing the size of shared
  57 libries is <a href="../apps/soreduce/README">The Shared Library
  58 Reduction (<CODE>soreduce</CODE>) tool</a>.  <code>soreduce</code>
  59 also benefits from the techniques listed above and should give
  60 results comparable to static linking.  In fact, when deploying multiple
  61 applications, use of shared libraries with <code>soreduce</code> will
  62 result in smaller overall footprint than static linking.</p>
  63
  64 <hr>
  65 <h3><a name="futurework">Future Work</a></h3>
  66 <p>
  67
  68 Depending on funding and contributions from the ACE community, future
  69 work on subsetting in ACE can be divided into two thrusts: <P>
  70
  71 <UL>
  72
  73 <LI> <B>Code refactoring</B>, which helps to reduce the coupling
  74 between applications and ACE C++ wrappers and frameworks.  The amount
  75 of coupling that's in ACE currently yields larger compiled size for
  76 executable applications, increased link times, and indirect dependency
  77 on a large amounts of code that may not be needed for many embedded
  78 applications. <P>
  79
  80 <LI> <B>Functionality Refactoring</B>, which enables application
  81 developers to choose lightweight reusable classes and frameworks,
  82 rather than monolithic and heavyweight implementations, to decrease
  83 compilation times, link times, and compiled memory footprint of
  84 embedded applications. <P>
  85
  86 </UL>
  87
  88 Our ideas for performing each of these thrusts is described in detail
  89 below.
  90
  91 <h4>ACE Code Refactoring</H4>
  92
  93 ACE is currently designed in such a way that application developers
  94 must link many classes and methods of ACE with their application, even
  95 if they use a small number of classes and functions in their
  96 application.  As a result, static memory resource utilization is
  97 unnecessarily high for common use cases.  This section describes
  98 techniques to address the existing code structuring complexities in
  99 ACE, which were originally driven by the poor quality of C++ tools
 100 that were available in the 1990's.  For example, early C++ compilers
 101 in the embedded domain lacked support for namespaces, which forced
 102 developers to write classes that had a number of utility functions
 103 useful for network programming.  Now that modern C++ compilers have
 104 better support for standard C++, we propose the following
 105 optimizations to ACE: <P>
 106
 107 <UL>
 108
 109 <LI> We will identify ACE classes and utility functions that serve a
 110    common goal, and move them into a namespace of their own.  Since C++
 111    allows a single namespace to be reopened in multiple translation
 112    units, we plan to split the operations into multiple C++ source
 113    files, giving the linker a chance to choose a smaller sized object
 114    files while creating an executable. <P>
 115
 116 <LI> Currently, ACE inlines many of its methods, which tradesoff run-time
 117    performance for larger footprint.  We propose to examine the contents
 118    of inlined files in ACE, and evaluate whether inlining is required in
 119    every instance.  ACE aggressively inlined functions to get better
 120    performance from the tool chains, but this has lead to increased code
 121    coupling within ACE, as well as increased coupling between
 122    applications that use ACE.  We will evaluate the tradeoffs associated
 123    with inlining and performance of certain functions and selectively
 124    inline those methods.  These optimizations are described further in
 125    <A
 126 HREF="http://www.amazon.com/exec/obidos/tg/detail/-/0201379503/104-7731669-1857527?v=glance">Efficient
 127 C++: Performance Programming Techniques</A> by Dov Bulka and
 128    David Mayhew.
 129 </UL>
 130
 131 We expect that we will be able to reduce footprint by ~25-30% for ACE
 132 applications, and a ~15-20% reduction in compile and link time of
 133 applications. <P>
 134
 135 <H4>Functionality Refactoring</H4>
 136
 137    This section proposes to address additional compile-time and memory
 138 footprint problems that can be solved by functionality refactoring.
 139 During the past decade, ACE has been designed and built based on many
 140 unique requirements from users around the globe.  Though this input
 141 enhanced the flexibility of ACE and increased the visibility of ACE,
 142 it also led to functionality "clumping," i.e., many classes in ACE
 143 have functionality associated with them that are not required for many
 144 applications.  For example, the ACE_Svc_Handler serves as an event
 145 handler for the ACE Reactor framework, serves as a handler to
 146 implement the thread-per-connection strategies, and can be dynamically
 147 loaded from shared libraries using the ACE Service Configurator
 148 framework, which in turn depends on the ACE Reactor framework.  Though
 149 all these dependencies and functionalities are required for some
 150 applications, they yield excessive coupling and overhead for
 151 applications (such as clients) that only want to use the ACE
 152 Acceptor/Connector framework to connect and send messages to remote
 153 servers. <P>
 154
 155    To address the issues of tight-coupling outlined above, we propose
 156 to refactor the code and functionality of the existing ACE frameworks
 157 and wrapper classes to offer finer-grained components that can be
 158 selectively included by embedded applications.  Our initial efforts
 159 would focus on the following key ACE frameworks:
 160 <UL>
 161 <LI> Logging
 162 <LI> Service Configurator
 163 <LI> Object Manager
 164 <LI> Reactor
 165 <LI> Framework Component
 166 <LI> Thread Manager
 167 <LI> Proactor
 168 </UL>
 169
 170 We propose to apply the techniques we have mentioned above.  As a
 171 result, we expect that we will be able to reduce footprint by another
 172 ~20-25% for certain classes of ACE applications, and a ~15-20%
 173 reduction in compile- and link-time of applications. <P>
 174
 175    Collectively, the optimizations we propose above will greatly
 176 reduce the memory footprint and speedup the compilation and link time
 177 for ACE-based applications. <P>
 178
 179 <p> Anyone interested in contributing time or funding to these efforts
 180 should please contact <a
 181 href="mailto:d.schmidt@vanderbilt.edu">d.schmidt@vanderbilt.edu</a>.
 182 If you have questions about ACE and/or ACE subsetting and footprint
 183 reduction please post these questions to <A
 184 HREF="https://github.com/DOCGroup/ACE_TAO">github issues
 185 or discussions</A>.</p>
 186
 187 <P><HR><P>
 188 Back to the <A HREF="http://www.dre.vanderbilt.edu/~schmidt/ACE.html">ACE</A>
 189 home page.<BR>
 190 Back to <A HREF="index.html">ACE Documentation Home</A>.
 191
 192 <!--#include virtual="/~schmidt/cgi-sig.html" -->
 193 </BODY>
 194 </HTML>