From: Magnus Holm Date: 2010-01-12T01:18:17+09:00 Subject: [ruby-core:27540] Re: better GC? Well, Rails itself is single-threaded and so are most of the servers. It's also fairy common with multi-cores for servers these days (maybe even for desktop too?). The obvious choice then is a concurrent garbage collector, which could run in it's own native thread (only locking the GIL for a small amount of time). Because of the GIL, only one thread can run at a time and there's no point of an on-the-fly which simplifies the case quite a lot. For instance, "Age-Oriented Concurrent Garbage Collection" by Paz, Petrank, Blackburn separates objects into two generations, but always collects both heaps. However, the older generation uses reference-counters which appears to be quite faster. Their implementation showed a max 2ms pause time, but I assume it will be even shorter when there's only one thread to stop. Petrank has also worked on the Stopless-collector which is both on-the-fly and real-time. It was implemented with "virtually no pause times, good mutator utilization, and acceptable overheads", and is next on my reading list. Frampton, Bacon, Cheng and Grove has been working on a real-time collector which has a 1ms max pause time. Also worth checking out I assume. // Magnus Holm 2010/1/11 Gon��alo Silva : > 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 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��alo 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 >> >> > >