GC refactor ahead

[Geoffrey Broadwell]

On Thu, 2009-11-26 at 10:01 -0800, chromatic wrote:
> On Thursday 26 November 2009 06:51:00 Patrick R. Michaud wrote:
> 
> > I don't quite understand this last comment.  Do short-lived objects
> > have a big impact on GC if they are created and then die before a GC
> > run is triggered?
> 
> They do, because we have to trace the entire live set on every GC run, even if 
> only 10% of the GCables created are live and 90% are short-lived.

I am somewhat suprised by this.  My expectation (and it sounds like
Patrick's as well) was that GC froth (items both created and destroyed
between GC runs) would be removed from the "live set" before the GC run
sees them -- and thus would not affect the execution time of the GC run.

It sounds like instead you're saying that creating an item adds it to
the live set, but dying does *not* remove it from the live set -- and
that only a full GC run can do this removal.

That sounds less than awesome, performance wise.

If the problem is that we don't know if the GCable has references to or
from it, and need to do a full GC run to resolve this, then it would be
nice if we could address this either through hinting or algorithmically.

If that's not the problem, then what is?


-'f