From: "Gonçalo Silva" Date: 2010-01-11T23:52:05+09:00 Subject: [ruby-core:27535] Re: better GC? --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 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 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 > > > > > > > > > --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).

= ---
Gon=E7alo S. Silva
http://go= ncalossilva.com

im: goncalossilva@gmail.com<= /a>
skype: goncalosantaremsilva
twitter: http://twitter.com/goncalossilva


On Mon, Jan 11, 2010 at 14:42, Erik Sche= irer <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. =A0 I think common code o= r 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 nu= mber
> of reachable objects, the mark phase can still take a long time. =A0Th= is
> is why a number of people want a generational collector, because it ca= n
> reduce the amount of time spent marking objects.
>
> IMO it's clear that there is no one-size-fits all option. =A0I won= der 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--