From: Evan Phoenix <evan@...>
Date: 2009-12-12T02:26:52+09:00
Subject: [ruby-core:27146] Re: Ruby's GC


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 <rick.denatale@gmail.com> 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", and 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 extensions and the GC that uses handles. These handles don't move, so C extensions can 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.
> 
>