[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=C3=A7alo Silva <[e-mail]>:
> 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=C3=A7alo S. Silva
> http://goncalossilva.com
>
> im: [e-mail]
> skype: goncalosantaremsilva
> twitter: http://twitter.com/goncalossilva
>
>
> On Mon, Jan 11, 2010 at 14:32, Paul Brannan <[e-mail]> 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. =C2=A0 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. =C2=A0T=
his
>> 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. =C2=A0I 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
>>
>>
>
>