--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&#39;s no need for it to be hot-pluggable, so there wouldn&#39;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">&lt;e / illume.org&gt;</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>
&gt; On Fri, Jan 08, 2010 at 07:37:40AM +0900, Kurt Stephens wrote:<br>
&gt;&gt; I&#39;m not convinced that the GC is the issue, but I haven&#39;t really been<br>
&gt;&gt; measuring it in production environments. I think common code or Ruby<br>
&gt;&gt; semantics that create avoidable garbage is the issue and would be an issue<br>
&gt;&gt; regardless of GC technology, including reference counting.<br>
&gt;<br>
&gt; Avoiding garbage doesn&#39;t solve the problem; if there is a large number<br>
&gt; of reachable objects, the mark phase can still take a long time. his<br>
&gt; is why a number of people want a generational collector, because it can<br>
&gt; reduce the amount of time spent marking objects.<br>
&gt;<br>
&gt; IMO it&#39;s clear that there is no one-size-fits all option.  wonder how<br>
&gt; difficult it would be to make the GC pluggable, so alternate GC&#39;s could<br>
&gt; be provided as gems?<br>
&gt;<br>
&gt; (obviously there would still be limitations on these GC&#39;s; an<br>
&gt; incremental collector would probably be out of the question).<br>
&gt;<br>
&gt; Paul<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
<br>
</div></div></blockquote></div><br>

--0015174bec341a17bd047ce4ae7d--