[omniORB] memory allocation problems and suggestions

[Jonathan Clark]

Comments of memory allocation
-------------------------------

I use my own garbage collection system which replaces the new & delete
operators.  I'm having trouble with omniorb because when it's linked in as a
DLL there are two different new & delete being resolved.

Some delete's are defined in header files and thus inlined or otherwise
linked against the main executable.   The main executable uses my GC
replacements for new & delete.   Most new's occur in the DLL which has
already been linked against the standard libc's new and delete operators.
Since new is called from one library and delete from another library,
obviously there are crashes.

Some possible solutions include :

#1 Move Omni's new/delete's out of header files and replace them with calls
that will be invoked by the DLL.  This may result in a slight efficiency
loss, however compared with the operation of delete it should not be
significant.

#2 Allow the user to specify a memory allocation/deallocation routine to
Omni's DLL.  This would be passed in as a pointer and default to
malloc/free.  i.e.   set_memory_helpers(my_malloc, my_free);   Then, you can
declare your own new and delete replacements for the dll version that call
the memory helper functions.   If not sure if all systems now support
overloading the new[] (new array) operator so you might run into trouble on
some ancient systems.  I remember some older versions of gcc and Metroworx
don't.

#3 link with static libraries instead of DLLs.  This should ensure all
routines use the same new/delete.
  This poses some problems as well.  Omni has some global constructors that
call new() before my garbage
  collector has a chance to initialize itself.
  In an ideal world omni should not call new until it is initialized (in
ORB_init).  Can you make this change
    easily?  We have a policy here that all cross library/module function
invocations must take place after main.
   This ensures all global constructors have had a chance to execute.  new
and delete fall into this category.
   If new() uses some library that needs global constructors then you are
stuck unless you get the link order
   just right - and that's not portable to all systems.

  For now I will use the static libraries and try to hack it so that my
garbage collector initializes itself
    when Omniorb tries to call new() - but I feel this is dirty code, and
look forward to correcting it. :-)

I would prefer to use a DLL solution while developing, but intend to
statically link for the final product.  If #2 or #3 cannot be implemented,
then I will just stick to statically linking.  #2 is the least "hacky" way
of solving the DLL problem.

I believe the problems I described carry over to Unix systems as well but I
haven't tried yet.

Jonathan