Minimum TAO

In addition to our work on ACE subsetting, we have also been reducing the footprint of TAO. We are pursuing two complementary strategies to reduce TAO's footprint:

1. Implicit subsetting, e.g., by reducing dependencies in the TAO library so that programs need not link unused TAO components.

2. Explicit subsetting, e.g., by supporting the minimumCORBA specification to TAO. The minimumCORBA specification removes the following features from the CORBA specification.
   • Dynamic Skeleton Interface
     
   • Dynamic Invocation Interface
     
   • Dynamic Any
     
   • Interceptors
     
   • Interface Repository
     
   • Advanced POA features
     
   • CORBA/COM interworking
     

1. Configure ACE to support only those components that are required by TAO and

2. Configure TAO to only support the components specified by the minimumCORBA specification.

Note: All measurement are for ACE 5.0 and TAO 1.0 using egcs-2.91.60 on SunOS5.7

The make flags options used were:

debug=0 optimize=1 static_libs_only=1 DEFFLAGS=-DACE_USE_RCSID=0

These options translate into:

• No debugging
• Optimization is set to -O2
• Static ACE and TAO libraries
• Use of RCS Ids is turned off

To build a TAO static library, if shared libraries are the default, use make static_libs_only=1 (make sure to do this for ACE, as well). If you're using recent versions of GNU GCC, you can use the -frepo option, which typically reduces the footprint by another 25 percent.

ACE+TAO Subsetting Work in Progress

• Log_Msg decoupling -- We have a good start on this, but it needs work to finish. It might be easiest to make an abstract base class, then have ACE_Log_Msg derive from it. That way we could remove the exposure of all the #includes in Log_Msg.cpp to applications that don't need it. Another alternative would be to disable compilation of Log_Msg.cpp when ACE_NLOGGING is enabled.

• Higher layer interdependencies -- We haven't exhaustively tested all possible combinations of subsets. It's possible that there are interdependencies between some layers that we haven't yet identified and removed.

• Remove reliance on multiple inheritance -- Multiple inheriance is only used in a few places in ACE. This isn't really a subsetting problem, but is necessary to fully take advantage of optimizations available on C++ compilers for embedded systems.

As the effort to reduce TAO's footprint continues, we are planning several modifications for TAO that should reduce the footprint for both the full CORBA and minimum CORBA configurations by around 300-400 Kbytes. The list below contains an estimate of the impact of each one of these changes, along with the estimated effort to implement them.

Component	Impact	Effort	Description
TAO	~95 Kb	2 weeks	Make RT CORBA 1.0 support optional, thereby allowing CORBA-compliant applications to link without incurring the overhead of TAO's RT CORBA features.
TAO	~50 kB	3 weeks	Make the CORBA Messaging components optional. This change requires making RT-CORBA optional first.
ACE	14 Kb	4 weeks	Implement a TAO-specific Reactor. ACE's reactor supports a number of features that TAO does not require. Thus, a TAO-specific implementation is an important way to reduce the footprint.
ACE	20 Kb	4 weeks	Implement a TAO-specific Service Configurator. TAO uses the ACE Service Configurator to dynamically configure its strategies. In many embedded applications the set of strategies are selected at design-time, on those platforms it would be appropriate to disable all the features to dynamically load components into the ORB.
TAO	10-15 Kb	1-2 weeks	Eliminate duplicate code due to instantiations of string -> pointer maps. TAO uses several such maps, they could be replaced by a generic version, wrapped with a fully inlined (i.e. zero footprint) adapter for type-safety.
TAO	3-10 Kb	1-2 weeks	Make message buffering strategies optional. TAO supports policy extensions to control the outgoing oneway and AMI request buffers. Those policies are not used by all applications.
TAO	10 Kb	2 weeks	Make support for multiple ORBs optional. TAO can support multiple ORBs in the same process, but most applications only require one.
TAO	<20 Kb	1 weeks	Use lower footprint alternatives to the ACE_Strategy_Acceptor and ACE_Strategy_Connector classes. TAO is using the most flexible classes in ACE to implement acceptors and connector, but does not take advantage of this flexibility.
TAO	5 Kb	1 week	Move the less common transport muxing and reply waiting strategies to an optional library.
ACE+TAO	30 Kb	8 weeks	Decouple ACE (and then TAO) from the ACE_Thread_Manager component. This component is only used in the thread-per-connection model, if we could decouple it in ACE then TAO could be modified to only link this component when that concurrency model is enabled.
TAO	>50 Kb	6 weeks	Move <<= and >>= operators to separate files. Currently TAO includes nearly 500 such operators, moving them to separate files (grouped by component?) would eliminate them from most applications.

In parallel with the activities described above we are pursuing other avenues of research to find sources of rarely used or unused code in ACE+TAO, and to modify the software to eliminate such code. These activities include the following:

• Using profiling tools, such as gprof, Quantify and True Coverage to find unreachable code, or code only reachable in certain applications.

• The code TAO's IDL compiler generates for CORBA::Any operators is large, so we are evaluating designs that reduce the impact of the CORBA::Any type support. TAO's IDL compiler already makes that support optional. However, for applications that require Anys it may be useful to separate that code in another file to reduce the size of generated stubs and skeletons, without losing the opportunity to use more dynamic CORBA invocation modes.

• The Notification Service currently depends on the Trading service to implement the Trader Constraint Language. We are planning to break that dependency and factor the TCL parser into a smaller library shared by both services.

• TAO still contains features that are rarely or never used. Examples include the interfaces to query the well-known services and to dynamically discover the level of security support. Those components should only be linked (dynamically) in applications that require them.

• The support for interceptors currently generated by the IDL compiler can be partially refactored into common ORB code. Moreover, we evaluating a new implementation of interceptors that can be configured dynamically, thereby eliminating the need for compile-time configuration flags.

• We are planning to provide compile-time flags to eliminate certain mandatory features in CORBA that are not used in all applications, such as IOR parsers (corbaloc, corbaname, etc.).

• Finally, we will perfom more code inspections to determine if template code can be refactored into base classes and thereby shared by many objects in the ACE+TAO implementations.