Re: Garbage collected types

George Neuner <gneuner2/>
21 Jul 2006 14:06:14 -0400

          From comp.compilers

Related articles
Garbage collected types (2006-07-18)
Re: Garbage collected types gneuner2/ (George Neuner) (2006-07-21)
| List of all articles for this month |

From: George Neuner <gneuner2/>
Newsgroups: comp.compilers
Date: 21 Jul 2006 14:06:14 -0400
Organization: Compilers Central
References: 06-07-041
Keywords: GC
Posted-Date: 21 Jul 2006 14:06:14 EDT

On 18 Jul 2006 14:05:05 -0400, wrote:

>I am working on a precise garbage collector. Since the garbage
>collector information won't be available for all types (and memory
>blocks), I will have problems when mixing garabage collected types and
>non garbage collected ones. My biggest concern is all the libraries
>allready compiled... they won't have my garbage collector support.
>I've been looking for articles about mixing both kind of types with
>not much sucess. Anyone could give me a hint about where to look for
>that kind of information or articles?
>I know I wouldn't have this problem with a conservative one, but as I
>said before, my intention is to build a precise garbage collector.

You'll still have a problem if the library has statically allocated
roots which your GC can't find and/or if the library uses it's own
(incompatible) allocator.

WRT precise collection for foreign code, I think you out of luck.
AFAIK, it's not possible to implement precise collection without
compiler support.

You might want to think about a hybrid. Bartlett, Detlef and Ellis
explored collectors that were precise in the heap but conservative in
the roots. Detlef and Ellis also did work on integrated use of
collected and uncollected heaps. A browse through their papers might
give you some ideas (sorry I don't have URLs to give you).

Also, Modula 3 has both traced (GC) and untraced heaps and allows
untraced pointers to be stored in the collected heap. I don't recall
just now whether it also allows traced pointers to be stored in the
uncollected heap. Even so, you might find something interesting

As an aside, I'm not terribly fond of finalizers. Whether or not the
language is OO, data "objects" can (and IMO should) have destructors -
which default to no action. I prefer a model that can destruct
objects independently of freeing their memory (Boehm-Demers-Weiser
does this for C++ but I haven't seen it anywhere else). A destructor
can manually free non-collected resources immediately if the object
falls out of scope while still relying on GC to reclaim the memory.
Obviously it doesn't help if you forget to write the destructor, but
in practice it is much harder to forget to close a lexical scope than
it is to forget to free or close something that won't get collected.


Post a followup to this message

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