I think there's no need for it to be hot-pluggable, so there wouldn't be an=
y
overhead at all (only at start, of course).

---
Gon=E7alo S. Silva
http://goncalossilva.com

im: goncalossilva / gmail.com
skype: goncalosantaremsilva
twitter: http://twitter.com/goncalossilva


On Mon, Jan 11, 2010 at 14:42, Erik Scheirer <e / illume.org> wrote:

> I think a pluggable/loadable GC scheme, as long as its really simple to
> use, is perfect.
>
> There would be some overhead created by making it pluggable, though, but =
in
> the scheme of things it would be well worth the small amount of cpu cycle=
s
> lost.
>
> Just my two-cents-worth ...
>
> e
>
> On Jan 11, 2010, at 9:32 AM, Paul Brannan wrote:
>
> > On Fri, Jan 08, 2010 at 07:37:40AM +0900, Kurt Stephens wrote:
> >> I'm not convinced that the GC is the issue, but I haven't really been
> >> measuring it in production environments.   I think common code or Ruby
> >> semantics that create avoidable garbage is the issue and would be an
> issue
> >> regardless of GC technology, including reference counting.
> >
> > Avoiding garbage doesn't solve the problem; if there is a large number
> > of reachable objects, the mark phase can still take a long time.  This
> > is why a number of people want a generational collector, because it can
> > reduce the amount of time spent marking objects.
> >
> > IMO it's clear that there is no one-size-fits all option.  I wonder how
> > difficult it would be to make the GC pluggable, so alternate GC's could
> > be provided as gems?
> >
> > (obviously there would still be limitations on these GC's; an
> > incremental collector would probably be out of the question).
> >
> > Paul
> >
> >
> >
>
>
>