For many years, builders of large-scale distributed object systems have relied on CORBA for implementing their infrastructure needs, in a time and cost effective manner. Middleware was the optimum place to share functionality, rather than duplicating it in every application. These systems were implemented at a time when the resources available to them, such as memory, processing power and expanded bandwidth became very cost effective. In this environment CORBA gained acceptance, more features were added, platform support extended and performance optimizations incorporated. TAO’s position in the market bears testimony to its leveraging of the growth in these resources to take CORBA beyond the best effort limitations of first generation CORBA products.
The features of TAO have made it very appealing to a wide variety of users. Now that its users are convinced of the benefits of CORBA in general, and of TAO in particular, they are seeking to extend its use. There are a new group of target hardware and software systems for object technologies, beyond the traditional desk-top and server systems. These new applications and their platforms are aimed at network control equipment, telephony devices, hand-held products, sensors, airborne systems, orbiting vehicles, industrial controllers and the like. This new class of computing machinery does not have the luxury of supporting such large shared objects. They have limitations on heat dissipation, unit costs, power consumption, battery size and weight, all of which make a small memory footprint a desirable characteristic. Configuring TAO for small memory usage by makes it attractive in a wider range of circumstances because it reduces initial cost, power consumption, heat emitted, physical size etc.
Footprint implications are a prime consideration in TAO’s continued development.
To see the latest progress in TAO’s footprint check with the web site http://www.dre.vanderbilt.edu/stats/footprint.shtml. All builds include an analysis of footprint size to encourage parsimonious coding practices, and to provide users with an open and transparent way of tracking status. Improvements today to the betas will manifest themselves in the next release product.
OCI has already contributed to TAO’s memory footprint reduction activities through sponsors. We are actively seeking additional sponsors to continue this activity.
One way to meet the need of this market is by making TAO more configurable, so that it can be tailored specifically for the embedded systems designer. This allows the OEM to derive the middleware from a standards compliant open source code base, and yet know the code is configured specific to the need at hand. Such tailoring is still cost effective compared with developing code from scratch. As TAO continues to add and evolve functionality, the OEM will still have a source of contemporary technology from which to refresh the product line.
The embedded and wireless systems market is presently undergoing dramatic change to meet the opportunities offered. New battery and other power source technologies, the latest software for power management, and new low power hardware, all of which are sensitive to the needs of the growing embedded market are constantly altering the mix of options available to the designers. A severe limitation today, maybe gone tomorrow. Middleware’s role is to absorb change and mask the developers from underlying systems’ turbulence, at both the hardware and O/S level. This benefit should not be denied lightly. TAO’s layer of abstraction provides a level of protection to the savvy designer.
When reviewing TAO, or in fact any ORB, for footprint size with regards to your application please consider the following:
The motivation for this tool was the understanding that the ACE & TAO libraries were to be linked with the VxWorks kernel to allow multiple applications to be run simultaneously with a minimum of footprint consumed. Ordinarily a choice is made between static linking applications, where each application gets only the object modules needed, and shared object linkage, where multiple applications share access to full libraries. Frequently a shared library will contain code and data which is not used by any of the applications in a particular configuration. The Shared Library Reduction Tool builds libraries that include only the modules needed to support a specified set of applications.
The analysis is performed very late in the application implementation, allowing the system implementers the freedom to use whatever TAO & ACE components are needed. Once an application is built and running, its shared object need may be evaluated. The evaluation is straight forward. Run the soreduce program, passing the path to all of the applications that will share the libraries. The soreduce program uses the following steps to generate its results.
For more information go to the $ACE_ROOT/apps/soreduce/README file.
In evaluating middleware, with regards to memory footprint, one must exercise care and good judgment.
Although the actual numbers are constantly changing (see the above URL) you may require a rule of thumb as to memory sizing. The LibACE size for Linux on X86 is about 700 kilobytes. On Vxworks for the PowerPC the size is around 850 kilobytes. LibTAO is just over a megabyte for the Linux/X86 combination and just under 1.4 megabytes for the VxWorks/PowerPC combination. Both are required for TAO. These numbers should help you obtain a general feel for the size of TAO on CISC and RISC environments.
Contact OCI if you are concerned about footprint and want to fairly evaluate TAO and ACE for your small footprint project.