This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Merge from pch branch; call for testers


> Cc: gcc@gcc.gnu.org
> From: Jim Wilson <wilson@redhat.com>
> Date: 23 May 2002 20:28:03 -0400
> User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
> 
> Maybe you could explain what the patch does?  You explained what it doesn't
> do, but not what it does do.  For example, what are all of the gengtype files
> for?  Also, if you don't want other people breaking it, you will need to
> tell us what we can and can't do anymore.

There's documentation to give the details, but basically what it does
is automatically generate routines to mark objects for GC.

The main new restriction is that pointers to GCable objects (allocated
with ggc_alloc, that live over a ggc_collect() call) need to be
either:

- Global variables, and marked as GC roots; or
- In a GCable object.

This isn't a hard requirement yet, because you don't have to use the
new stuff, but I want to remove all the old stuff (that is,
ggc_add_root) so I'd appreciate it if people didn't add any new uses
of it.

It's hard to accidentally break it without causing a build failure or
a crash the first time garbage collection happens.

This is important for things like generational GC; if you want to make
objects read-only, it helps a lot to have allocated those objects in
the first place.  It also makes it much easier to implement a
compacting collector, because it's easier to find out where all the
pointers to a particular object are.  It has advantages for
precompiled headers for pretty much the same reasons.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]