Re: Adding garbage collection to C++

tmb@idiap.ch writes:
>>[C lets you hide pointers in inconvenient ways, e.g. writing them to
>>files or scrambling bytes in unions.]
>
>All the locations where a pointer is converted to an integer (via casts,
>unions, or memcpy) are detectable by the compiler. For any pointer that
>has ever been (mis-)treated in such a way, the corresponding memory can
>simply be exempted from garbage collection (e.g., by recording the pointer
>in some global table searched by the garbage collector).


This may be true in theory, but it seems like it would be very difficult
in practice (especially if you allow seperate compilation) and might lead
to memory leaks.


Presumeably you have to consider every conversion from (T **) to (void *)
potentially dangerous, since the (void *) could be used to hide away the
(T *) pointer, using memcpy(), fwrite(), or some such. But such
conversions may be relatively common.


For example, if you want to sort an array of strings, then you will
probably pass a (char **) to qsort() where it expects a (void *).
Presumably the compiler is not going to be smart enough to tell the
difference between qsort() and fwrite(), which both take a void *
parameter. If instead you happened to be using a user-defined sort
function that has not yet been written or compiled, then there is no way
it could tell! This means that it will have to assume that qsort might
hide a copy of the pointers somewhere, so the compiler must record the
pointers in the global table.


Now if you were actually relying on GC to reclaim that memory, you're
stuffed, because the compiler can never be sure that qsort() hasn't
secretly written the addresses to a file, so it has to keep the memory
hanging around. This is a memory leak.


If your GC doesn't prevent memory leaks, not many people will use it :-)


--
Fergus Henderson fjh@munta.cs.mu.OZ.AU
--

Return to the comp.compilers page.
Search the comp.compilers archives again.