[ruby-core:27586] Re: better GC?

On Wed, Jan 13, 2010 at 9:03 PM, Joe Damato <[e-mail]> wrote:
> On Tue, Jan 12, 2010 at 12:45 PM, Evan Phoenix <[e-mail]> wro=
te:
>>
>> On Jan 11, 2010, at 2:58 PM, Roger Pack wrote:
>>
>>>>> I wonder if its GC could be merged into MRI :)
>>>>
>>>> Nope.
>>>
>>> Explanation? (Licensing problem?)
>>
>> The Rubinius GC (there are actually 3 of them) require write barriers. T=
o port to MRI, you'd have to rewrite most of the internals to use write bar=
riers, and then no extensions would work because the GCs are accurate only =
(no conservative stack scanning), and they require the ability to move obje=
cts.
>>
>
>
> You could do it without rewriting the MRI internals AND retaining
> compatibility with extensions..
>
> BUT
>
> it would be painfully slow, probably unusable.

OK so the way I see this is:

retain backward compatibility  VS   implement write barriers toward a
more intelligent GC.

How about we implement the primitives and just punish people who use
the "old" way of touching objects?

How about:

- Expose an API for accessing object internals so that write barriers
can be implemented in software.

and

- At the same time continue to allow extensions to reach in and touch
MRI internals, for the time being. These objects could have their
barriers implemented in hardware. The performance penalty will be HIGH
but perhaps this is good motivation for people to fix their ruby gems?

Perhaps this is too mean?

joe