## 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.

### Contents

- Past Work
- Future Work

### Past Work

Previous ACE+TAO subsetting efforts were mainly concerned with breaking up ACE into multiple libraries. Although this is a worthy goal, the existing component definitions in ace.mpc are too tighly coupled. Therefore, even if ACE is compiled into multiple libraries, applications will 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:

- Code refactoring, 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.

- Functionality Refactoring, 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.

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 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.

- 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 Efficient C++: Performance Programming Techniques by Dov Bulka and David Mayhew.

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:

- Logging
- Service Configurator
- Object Manager
- Reactor
- Framework Component
- Thread Manager
- Proactor

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 d.schmidt@vanderbilt.edu. 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.