[ruby-core:27147] Re: Ruby's GC

Then because of C extensions support the generational GC is not an option.

What would then be the best algorithm for a GC for Ruby? Mark and don't
sweep? A non-halting algorithm would be great.
---
Gon=E7alo S. Silva
http://goncalossilva.com

im: [e-mail]
skype: goncalosantaremsilva
twitter: http://twitter.com/goncalossilva


On Fri, Dec 11, 2009 at 17:26, Evan Phoenix <[e-mail]> wrote:

>
> On Dec 11, 2009, at 7:08 AM, Yukihiro Matsumoto wrote:
>
> > Hi,
> >
> > In message "Re: [ruby-core:27144] Re: Ruby's GC"
> >    on Fri, 11 Dec 2009 23:57:24 +0900, Rick DeNatale <
> [e-mail]> writes:
> >
> > |I suspect that the write barrier can be implemented rather efficiently
> > |depending on how memory layout is done. You need to be able to
> > |efficiently distinguish between mutations to references in old objects
> > |(which need to be remembered) and mutations in new objects, which
> > |don't.
> > |
> > |One interesting problem, is what effect a copying GC would have on the
> > |API to C extensions, since object addresses would no longer be stable
> > |over time.
> >
> > Non conservative GC would damage almost all C extensions for Ruby.
> > I don't think it's acceptable for CRuby.
>
> A copy collector would also break almost all C extensions, because it's
> common for people to store a reference to an object somewhere "secret", a=
nd
> then store in somewhere normal to keep it alive. Because the current GC
> doesn't move objects, the "secret" reference stays valid as long as the
> object lives.
>
> With a copy collector, all references need to be fixed up, so the "secret=
"
> references would be invalidated.
>
> For Rubinius, we implemented an indirection layer between the C extension=
s
> and the GC that uses handles. These handles don't move, so C extensions c=
an
> store "secret" references to them and GC can still move things behind the
> scene, so long as the handle is internally updated.
>
> > Regarding of copying GC, one thing I have interest is how its
> > copy-on-write unfriendliness effect the performance under Web
> > environment.
> >
> >                                                       matz.
> >
> >
>
>
>