This is the mail archive of the gcc-patches@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: [patch] Move loop structures to gc memory


On Mon, May 14, 2007 at 04:24:45PM -0700, Ian Lance Taylor wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > On Mon, May 14, 2007 at 03:37:40PM -0700, Ian Lance Taylor wrote:
> > > Why do we need the strategy of "GC with explicit death marking?"  What
> > > goal does that serve?
> > 
> > Exactly this problem.  Which comes up several times a year.
> 
> How would you characterize the problem being solved?  (It's a serious
> question.)

I would characterize it as data with a precisely identifiable
lifetime, where there is some other advantage to storing it in GC
memory.

Case A: Every "struct foo" has precisely known lifetime, but they
contain GC'd pointers and we want to collect while they're live.
This case.  A bit tricky to get around; there could be a lot of them,
and the roots list would not scale well if we had to add and remove
them dynamically.  It'd have to be a pointer set instead except we
need type info too.

Case B: Some "struct foo" have precisely known lifetimes, others
don't.  For instance, suppose we built up information about
interesting loops in GC memory; we might want to save the data until
indefinitely later, except that during the build-up process we
disqualify some loops from interestingness.  We could ggc_free
them, and as a bonus with appropriate checking this would make sure
later passes weren't bogusly looking at boring loops.

Does that clarify the need I see?

-- 
Daniel Jacobowitz
CodeSourcery


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