From: "Gonçalo Silva" Date: 2010-01-11T23:37:07+09:00 Subject: [ruby-core:27533] Re: better GC? --00032555929a7637f3047ce478d5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's an interesting idea, Paul. I love it but I think it would imply a lo= t of effort from a lot of people, specially because some GC implementations will cause breakages on some C extensions. Anyway, what would be the best GC implementation for a Rails application? Since Rails is one of the most important Ruby projects, growing and being used worldwide, I really think that some effort should be put into optimizing Ruby for Rails and that includes it's GC. --- 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:32, 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 > > > --00032555929a7637f3047ce478d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's an interesting idea, Paul. I love it but I think it would imply = a lot of effort from a lot of people, specially because some GC implementat= ions will cause breakages on some C extensions.

Anyway, = what would be the best GC implementation for a Rails application? Since Rai= ls is one of the most important Ruby projects, growing and being used world= wide, I really think that some effort should be put into optimizing Ruby fo= r Rails and that includes it's GC.

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

im: goncalossilva@gmail.com
skype: goncalosantaremsilva
twitt= er: http://twitter.com/goncalo= ssilva


On Mon, Jan 11, 2010 at 14:32, Paul Bran= nan <pbrannan@a= tdesk.com> wrote:
On Fri, Jan 08, 2010 at 07:37:40AM +0900, Kurt Stephens w= rote:
> I'm not convinced that the GC is the issue, but I haven't real= ly been
> measuring it in production environments. =A0 I think common code or Ru= by
> semantics that create avoidable garbage is the issue and would be an i= ssue
> regardless of GC technology, including reference counting.

Avoiding garbage doesn't solve the problem; if there is a large n= umber
of reachable objects, the mark phase can still take a long time. =A0This 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. =A0I wonder h= ow
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



--00032555929a7637f3047ce478d5--