ACE+TAO Subsetting

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.


Past Work

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 ace.mpc are too tightly coupled. Even if ACE was compiled into multiple libraries, therefore, applications would still have to link almost every one of them.

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.

In fact, this technique was applied systematically to ACE_OS in 2003, and resulted in a 10-15% decrease in overall footprint for statically linked applications. Interestingly, these techniques also helped reduce compilation times by ~50%.

Another very powerful technique for reducing the size of shared libries is The Shared Library Reduction (soreduce) tool. soreduce 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 soreduce will result in smaller overall footprint than static linking.

Future Work

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

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

ACE Code Refactoring

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:

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.

Functionality Refactoring

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.

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:

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.

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

Anyone interested in contributing time or funding to these efforts should please contact If you have questions about ACE and/or ACE subsetting and footprint reduction please post these questions to the ACE mailing list.

Back to the ACE home page.
Back to ACE Documentation Home.