ChangeLogTag:Sat Oct 23 11:27:47 2004 Douglas C. Schmidt <schmidt@cs.wustl.edu>

1 files changed, 113 insertions, 8 deletions

diff --git a/docs/ACE-subsets.html b/docs/ACE-subsets.html
index 31d2bdec068..832bae76b17 100644
--- a/docs/ACE-subsets.html
+++ b/docs/ACE-subsets.html
@@ -65,16 +65,121 @@ result in smaller overall footprint than static linking.</p>
 <hr>
 <h3><a name="futurework">Future Work</a></h3>
 <p>
-Future work includes converting additional classes to namespaces,
-e.g., ACE, modifying inlines to reduce unneeded coupling, and
-refactoring some of the ubiquitous classes and frameworks in ACE, e.g.,
-Logging, to further reduce coupling (which should make it possible to
-break up ACE into multiple independent libraries).</p>  
 
-<p>
-Anyone interested in contributing to the effort should contact <a
-href="mailto:d.hinton@vanderbilt.edu">d.hinton@vanderbilt.edu</a>.</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.hinton@vanderbilt.edu">d.hinton@vanderbilt.edu</a>.</p>
 
 <P><HR><P>
 Back to the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A>