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

On Fri, Dec 11, 2009 at 12:26 PM, 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"
>> =A0 =A0on 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 c=
ommon 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 doe=
sn'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 th=
e scene, so long as the handle is internally updated.

Right, and that's what I was hinting at.

I don't think that it's an issue of conservative vs. precise GC, the
trick of storing a reference to an object with a 'secret' pointer
someplace normal deals with objects being freed behind one's back.

But there have been implementations for languages like Smalltalk with
both a copying GC, and an api for writing extensions in C or C
equivalents which provides for the extensions working despite moving
objects.

Also there's a difference between extensions which are merely wrappers
on external function libraries, and those which are new VM primitives.
 The latter know that they are dealing with objects in the host
language, while the former do not, any objects need to be converted to
datatypes understood by the code being called so no object pointers
cross the API.

And when extensions which know about objects deal with them they need
to deal with them through macros and functions provided by the
implementation.  Even with MRI, C code can't simply treat an object
reference as a pointer, it needs to use the macros and rb_functions to
convert the VALUE type to something which the extension code can deal
with.

So I suspect that it might be possible to maintain the existing MRI
extension interface at the source level in the face of a copying
collector, but the extensions would need to be recompiled and would
not be binary compatible.

But we have that level of incompatibility at least between Ruby 1.8.x
and Ruby 1.9.x extensions.  So I don't think it should be an
impediment to having a copying GC, with it's benefits, in a future
Ruby implementation.

Even better if the api for primitives could be made (more)
implementation independent sort of like an FFI for primitives rather
than library wrappers.

--=20
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale