Re: Garbage collected types

On 18 Jul 2006 14:05:05 -0400, frankalahan@xxxxxxxxx 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
there.

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.


George
.

Relevant Pages

  • Re: Lcc-win32 extensions to C
    ... compiled with a C++ compiler or a C compiler. ... Yes, but if you do not use GC, you allocate more memory than needed to ... Using a non-GC'ed heap+ a GC'ed heap requires also more memory... ... Collector, since GC technologies are much more advanced than simple ...
    (comp.std.c)
  • Re: to dispose or not ?
    ... The dotNet garbage collector is, at it's heart, a move to another heap style collector for the Gen0 and Gen1 heaps and a mark/sweep/compact collector for the Gen2 heap. ... Setting an object to Nothing simply releases the reference from the variable to the object in the heap. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: to dispose or not ?
    ... always have the system memory roots available. ... collector for the Gen0 and Gen1 heaps and a mark/sweep/compact collector for ... heap or compacts free space out of the heap. ... the reference from the variable to the object in the heap. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: to dispose or not ?
    ... always have the system memory roots available. ... It also means that MS took some shortcuts in the garbage collector to improve the performance of finalizers. ... the reference from the variable to the object in the heap. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Memory Allocation?
    ... we shouldn't need access to the Garbage Collector ... I answered earlier that the *way* CPython allocates and uses memory it ... from writing a memory profiler;) ...
    (comp.lang.python)