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

On Dec 11, 2009, at 7:08 AM, Yukihiro Matsumoto wrote:

> Hi,
>=20
> In message "Re: [ruby-core:27144] Re: Ruby's GC"
>    on Fri, 11 Dec 2009 23:57:24 +0900, Rick DeNatale =
<[e-mail]> writes:
>=20
> |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.
>=20
> 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.
>=20
> 							matz.
>=20
>=20