This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Garbage collection & implicit delete operator in destructor catch-22
- From: "Peter Blemel" <pblemel at hotmail dot com>
- To: java-patches at gcc dot gnu dot org
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 15 Sep 2004 12:25:49 -0600
- Subject: Garbage collection & implicit delete operator in destructor catch-22
- Bcc:
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