--0015174bec341a17bd047ce4ae7d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think there's no need for it to be hot-pluggable, so there wouldn't be any overhead at all (only at start, of course). --- GoníÂlo 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 cycles > 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 > > > > > > > > > --0015174bec341a17bd047ce4ae7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think there's no need for it to be hot-pluggable, so there wouldn't be any overhead at all (only at start, of course).<br clear="all"><br>---<br>GoníÂlo S. Silva<br>http://goncalossilva.com<br> <br>im: goncalossilva / gmail.com<br>skype: goncalosantaremsilva<br>twitter: http://twitter.com/goncalossilva<br> <br><br><div class="gmail_quote">On Mon, Jan 11, 2010 at 14:42, Erik Scheirer <span dir="ltr"><e / illume.org></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 08ex;border-left:1px #ccc solid;padding-left:1ex;"> I think a pluggable/loadable GC scheme, as long as its really simple to use, is perfect.<br> <br> There would be some overhead created by making it pluggable, though, but inhe scheme of things it would be well worth the small amount of cpu cyclesost.<br> <br> Just my two-cents-worth ...<br> <font color="#888888"><br> e<br> </font><div><div></div><div class="h5"><br> On Jan 11, 2010, at 9:32 AM, Paul Brannan wrote:<br> <br> > On Fri, Jan 08, 2010 at 07:37:40AM +0900, Kurt Stephens wrote:<br> >> I'm not convinced that the GC is the issue, but I haven't really been<br> >> measuring it in production environments. I think common code or Ruby<br> >> semantics that create avoidable garbage is the issue and would be an issue<br> >> regardless of GC technology, including reference counting.<br> ><br> > Avoiding garbage doesn't solve the problem; if there is a large number<br> > of reachable objects, the mark phase can still take a long time. his<br> > is why a number of people want a generational collector, because it can<br> > reduce the amount of time spent marking objects.<br> ><br> > IMO it's clear that there is no one-size-fits all option. wonder how<br> > difficult it would be to make the GC pluggable, so alternate GC's could<br> > be provided as gems?<br> ><br> > (obviously there would still be limitations on these GC's; an<br> > incremental collector would probably be out of the question).<br> ><br> > Paul<br> ><br> ><br> ><br> <br> <br> </div></div></blockquote></div><br> --0015174bec341a17bd047ce4ae7d--