|Garbage Collector for C Wanted firstname.lastname@example.org (1993-07-12)|
|Re: Garbage Collector for C Wanted N.Winton@axion.bt.co.uk (1993-07-19)|
|Re: Garbage Collector for C Wanted email@example.com (1993-07-19)|
|Re: Garbage Collector for C Wanted firstname.lastname@example.org (1993-07-20)|
|From:||email@example.com (Hans Boehm)|
|Keywords:||C, GC, FTP|
|Date:||Mon, 19 Jul 1993 22:16:50 GMT|
N.Winton@axion.bt.co.uk (Neil Winton) writes:
>Errm, well not exatly what you are looking for but I have written a
>drop-in replacement for malloc() which does a mark-and-sweep GC for C. I
>don't know whether I can release (probably not) ...
There is a collector in parcftp.xerox.com:pub/russell/gc.tar.Z that does
exactly this. There is also an incremental version (version 3.0) in the
same directory, but it's not quite ready for prime time yet. This runs
under many UNIX versions and OS/2.
Codewright's Toolworks (with which I am not associated) sells something
vaguely similar for PCs running DOS.
>Oh, I also did a set of wrapper routines which used the same philosophy to
>do the mark-and-sweep but which don't require that you replace malloc().
You can get significantly better performance by building an allocator that
cooperates more with the garbage collector. For example, with
sufficiently small average object size, our collector often outperforms
malloc/free, since en masse deallocation can be much cheaper than many
free calls. It's also cheaper to allocate objects so as to minimize the
danger of integers "pointing to" the heap.
Return to the
Search the comp.compilers archives again.