Garbage collection & implicit delete operator in destructor catch-22

["Peter Blemel" <pblemel at hotmail dot com>]

Hello World,

I am working on an Embedded PowerPC port of the compiler tool chain.    The 
RTOS that I am using does not provide any dynamic memory management library 
of the malloc/new/delete type flavor.   The compiler, however, emits an 
implicit delete in a class's destructor.

The first question is "why?".   My (admittedly limited) understanding is 
that the destructor is invoked by the delete operator, not the other way 
around.   An object being deleted 'from the stack' when leaving a scope 
doesn't need to invoke delete, and delete has to be explicitly called on 
objects allocated by 'new' (except for garbage collection, which is where my 
problem starts).

The RTOS image loader requires that there be no undefined symbols in a 
shared object (so/dll) because this is read-only code used by multiple 
processes.   Linking against other dlls is permitted.  Our initial work 
around was to just define an empty delete operator within a "stubs" DLL and 
link other shared libraries against it.   This is where the trouble starts.  
We now have two classes of applications running.  Those that must have 
guaranteed determinism and those that don't.   Those that must be 
deterministic use a simple home grown heap based allocation 'new' operator.  
They invoke 'new' a fixed (predetermined) number of times during program 
start up.  This basically just partitions a block of memory in the 
uninitialized data segment, and it's never called after program startup.  
They never ask the operating system for more space and they never invoke the 
delete operator, which is why a 'stub' function worked.   A more advanced 
memory management library would just add uneeded complexity and latency.

That brings me to those applications that don't need to be deterministic and 
can take advantage of boehm-gc (namely, I want to run gcj/libgcj java 
applications).  These applications use new/delete/malloc/free from the 
boehm-gc library, but some of the classes that they need to allocate in CNI 
functions are found in the other shared libraries, which have been linked 
with a stub delete operator.   That makes the second question "do I care"?   
If explicitly delete an object in such an application, which invokes the 
destructor, and the destructor invokes the dummy delete operator that it was 
linked against, is there really a problem?    Does the garbage collector 
finalization expect the destructor to invoke the delete operator?

Thanks and regards,
Peter

_________________________________________________________________
Get ready for school! Find articles, homework help and more in the Back to 
School Guide! http://special.msn.com/network/04backtoschool.armx