Possible todo's

- Typecode library
- Look at SystemException, looks like all possible SystemExceptions are
linked into the app, not just the ones that are used. The SystemException.o
is more then 60Kb
- Look if maybe we have multiple classes in one source file where we only
use one of them, split the file then
- Check is we don't use virtual methods that are not needed (for example
ACE_Reactor/ACE_Proactor/ACE_Reactor_Timer_Interface) and that we don't
export classes from the dll that shouldn't be exported
- CodeSet library

Drop exception specifications (bug 1852)

The RTCorba library hasn't been reviewed for footprint usage in the reductions
we did until now. For example the RTCorba uses PortableInterceptor functionality
to register things to the ORB, this makes the RTCorba lib dependent on the PI
lib, when we can prevent that it would safe footprint for the application.

Reworking the Active Object Map in the POA to because of the recent POA
refactoring can give us some more performance.

- Look into the possibility of lightweight hash tables, specialized for common 
keys like string and integer.

Anys depend on typecodes, so they will have to be moved as well if a typecode 
library is created.

- OS_NS_Thread, Mutex, Condition etc. contain quite some code for System-scope 
(process shared) synchronization which AFAIK is not used for TAO.
How about a 'lean and mean' compileswitch to exclude this code for a TAO-only 
build of libCAE?
Downside is of course the functionality not being available for 
applicationcode as well.

- Refactor code to remove workarounds for newer versions of OSes providing 
better lowlevel support (like f.i. much improved POSIX support in latest 
Linux kernels using NPTL threads).

- Don't know how much this overlaps with ideas about 'Object File Profiling'. 
Service_Configurator framework is a non-trivial piece of code which might be 
replaced by a 'deployment tool' which generates a tailored piece of code 
instead based on a 'service configuration' (which might even be identical to 
the directives for the Service_Configurator framework).

- ORB_Core contains a non-trivial piece of code to process -ORBxxx directives.
For a more static deployment this might be replaced by compiletime 
defaults/tailored code (possibly generated).

For SystemException it seems only possible according to Ossama to split it in
multiple files, other options have been tried in the past. Maybe make a core
system exception with the things used by the orb core, the other exceptions in
other files.

There may indeed be other things we can do for SystemException.cpp besides
splitting it up, but I believe that we have exhausted the more obvious solutions.

For Anys, I think that we can move:

     1. Any*
     2. *TypeCode*
     3. probably a good chunk of append.cpp, skip.cpp and Marshal.*.
 
to a separate library.  Jeff does that sound correct and feasible?

Added more footprint related BTS entries.

For documentation purposes ...

PortableInterceptor support (including ORBInitializers, CodecFactory, etc) has
been decoupled from the ORB core.

An ACE_Array_Map class template was added to ACE.  It is a light weight
array-based map implementation with an STL-like map interface.  ACE_Array_Map is
suitable for small collections in areas of code that can tolerate linear
searches, or large collections in areas of code that can benefit from fast map
iteration.

Move TAO_Encodable from the TAO lib to the TAO Utils lib. Remove the usage of
this in RTCorba, not needed. Just an utility class

Move Pollable.pidl and generated files to the Messaging lib. Just defined
interfaces which are not used. Ossama/Jeff agree to move them to the Messaging lib.

Hi Johnny,

On Tue, 2005-07-05 at 20:46 +0200, Johnny Willemsen wrote:
> I think that if will be a few files. For example we have systemexceptions
> for transaction problems, we don't use them, so let us try to get them out.

Right!  Others could be:

      * IMP_LIMIT
      * BAD_TYPECODE (maybe for the Any library?)
      * NO_RESPONSE
      * PERSIST_STORE
      * FREE_MEM
      * INV_IDENT
      * INV_FLAG
      * BAD_CONTEXT
      * REBIND
      * BAD_QOS
      * INVALID_ACTIVITY
      * ACTIVITY_COMPLETED
      * ACTIVITY_REQUIRED
      * THREAD_CANCELLED

I haven't verified if these are unused in TAO, however.

-Ossama
-- 
Ossama Othman <ossama@dre.vanderbilt.edu>

Added bug 1917 as depends on, updating the exceptionholder for AMI will reduce
footprint when AMI is used

> 
> On Wed, 2005-07-06 at 20:13 +0200, Johnny Willemsen wrote:
> > Thanks for the info. Some time ago we talked about a 
> separate TypeCode
> > library. What are your ideas on that, I see typecodes here 
> again, would such
> > a library now be usefull? Ossama, you had ideas on that, 
> maybe we should
> > create that lib now?
> 
> I'm inclined to lump TypeCodes with the proposed Any library 
> since there
> aren't many uses of TypeCodes without Anys;  the Interface Repository
> being the obvious exception.  Jeff, do you concur?

Even the IFR (both client and service) will have to link in Anys,
I think, since this is in the IDL for IFR_Client:

  struct UnionMember
  {
    Identifier name;
    any label;
    TypeCode type;
    IDLType type_def;
  };

So I think it makes sense to keep Anys and TypeCodes together.

Here's a list of all files
in TAO/tao (except *A.* files, and Any-related files) that include
Any.h:

ClientRequestInfo.cpp
ClientRequestInfoC.h
Dynamic_ParameterC.h
NVList.h
PICurrent.h
PICurrent_Impl.h
PICurrentC.h
RequestInfoC.h
ServerRequestInfoC.h

NVList is something I'd like to move to DynamicInterface - however,
ORB.cpp includes NVList.h, because of its methods create_list() and
create_named_value(). Probably we should implement these using the
Object_Loader scheme that is already used for the typecode creation
methods and other stuff in CORBA::ORB. Most of the others include
Any.h because the corresponding .pidl file contains an Any.

Looks like the only Policy-related dependency on Anys is in
PolicyFactory, which has been moved out to the PI library. Is this
the right place for PolicyFactory? Other things besides interceptors
use policies, right?

Well, that's all I get right now from a quick once-over of TAO/tao.

Added some more footprint reduction items as depends on

Fix the split=1, see below from ace-users

Hi Brent,

>> Has anyone tried to compile ACE with the split=1 option set?  (Since
>> the build is broken in multiple places, I'm betting the answer is no.)

Yes, the answer is "no" ;-)

>> The split-cpp utility trips over every .cpp file that splits the
>> ACE_RCSID() macro across multiple lines e.g. Local_Name_Space.cpp.
>> In addition, files such as Codecs.cpp that call sizeof() on arrays
>> fail to compile, because the array is defined in a separate .cpp
>> files ("error: invalid application of `sizeof' to an incomplete
>> type").
>>
>> If this feature is no longer supported, then it should probably be
>> removed from ACE-INSTALL (section "Makefile Flags") and maybe
>> include/makeinclude/rules.local.GNU .

Alternatively, it would be nice to fix the split-cpp utility so that
it works.  This may be a "win" for the footprint reduction activities
we're involved with for various sponsors.  Johnny, can you please add
this to the "metabug" in bugzilla entry 2181?  Brent, it'll take us
several months to get around to doing this, so if you'd like to jump
in and help us out that would be great.

NVList moving to DynamicInterface seems not real a good solution. This resulted
in the fact that IFR_Client was made dependent on DynamicInterface. After
checking with Jeff he proposed to move NVList also to the new lib that will
contain Any/Typecode. 

It would probably reduce footprint and improve performance to implement
Atomic_Op <unsigned long, mutex) with a specialization. Use the specific cpu
instructions some cpu's have. 

Added 2193 as another dependencies. Since it is quite easy and the right thing
to eliminate the ACE_Service_Object inheritance, thus eliminating resundent
reactor_ data member

Just for the record, I do not agree that removing the ACE_Service_Object
inheritance from ACE_Connector is desireable or right.

Adding these in case they are not mentioned anywhere else:

- try to get a lightweight specialization of ACE_Hash_Map
that uses string for external key

- look into Bala's suggestion of separating PI functionality
into two parts

- see what more can be done toward getting a minimum POA
(Maybe this is already happening under the hood due to
Johnny's POA changes of a while back. If there is a specific
server configuration needed to link only minimum POA stuff,
we should have a test for this in which the footprint is
checked, since it's a good bet some checkin will break it
before too long. If this is not the case now, we should
work on factoring out a minimum POA, and getting rid of
TAO_HAS_MINIMUM_POA).

- see if we can streamline the CDR classes for TAO. In
particualr, ACE_Message_Block and ACE_Data_Block are
large classes.

added depends

added 2627

added 2626

added 2630

added depends

added depends

enhancement