[gclist] GCC 3.0 and GC?

[Boehm, Hans]

Our collector is used in the Java (gcj) runtime.  As a result, it is part of
the gcc source tree.  I've been working on improving the interaction between
libgcj and the collector, though a lot of that didn't make it into gcc 3.0.

My understanding is that gcc itself uses a custom garbage collector to
manage the "tree" intermediate
code.  AFAIK, it does not ever use our collector for this purpose.  It was
motivated by the increasing complexity of memory management in gcc
front-ends.  It does provide for different plug-in collectors.  See ggc* in
the main gcc source directory.  The interface to these collectors is very
specific to the gcc tree data structure.

I could not quickly find the discussion that led up to this, though it may
well have occurred on the gcc mailing list.

Hans

> -----Original Message-----
> From: Gabriel Dos Reis [mailto:Gabriel.Dos-Reis@cmla.ens-cachan.fr]
> Sent: Monday, June 18, 2001 7:50 AM
> To: gclist@iecc.com
> Subject: Re: [gclist] GCC 3.0 and GC?
> 
> 
> Daniel Wang <danwang@CS.Princeton.EDU> writes:
> 
> | >From 
> | 
> |  http://gcc.gnu.org/gcc-3.0/features.html
> | 
> | New Languages and Language specific improvements: 
> |   The GNU Compiler for the Java(TM) language (GCJ) is now 
> integrated and
> |   supported, ...  and the Boehm conservative garbage collector.
> | 
> | Other significant improvements: Garbage collection used 
> internally by the
> |    compiler for most memory allocation instead of obstacks.
> | 
> | So does this mean GCC is now using the Bohem conservative 
> collector? Or is
> | gcc using a different GC internally. 
> 
> GCC is now using the Bohem collector.
> 
> | ... I'm generally, curious as to why the
> | GCC developers decided to take the plunge and adopt GC. 
> 
> Using a GC in lieu of obstack hackery makes it easier to fix some
> obscure bugs.  That also simplifies considerably the compiler.
> 
> -- Gaby
>