From: "Gonçalo Silva" Date: 2010-01-15T02:50:54+09:00 Subject: [ruby-core:27589] Re: better GC? --00032555a19a1e86af047d2387c0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So, we're getting the worse of the two options. GC will still be slow and people will need to fix their ruby gems. I don't see how this is good for u= s or Ruby itself. On Thu, Jan 14, 2010 at 05:14, Joe Damato wrote: > On Wed, Jan 13, 2010 at 9:03 PM, Joe Damato wrote: > > On Tue, Jan 12, 2010 at 12:45 PM, Evan Phoenix > wrote: > >> > >> 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. > To port to MRI, you'd have to rewrite most of the internals to use write > barriers, and then no extensions would work because the GCs are accurate > only (no conservative stack scanning), and they require the ability to mo= ve > objects. > >> > > > > > > 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 > > --=20 --- Gon=E7alo S. Silva http://goncalossilva.com im: goncalossilva@gmail.com skype: goncalosantaremsilva twitter: http://twitter.com/goncalossilva --00032555a19a1e86af047d2387c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So, we're getting the worse of the two options. GC will still be slow a= nd people will need to fix their ruby gems. I don't see how this is goo= d for us or Ruby itself.

On Thu, Jan 14, = 2010 at 05:14, Joe Damato <ice799@gmail.com> wrote:
On Wed, Jan 13, 2010 at 9= :03 PM, Joe Damato <ice799@gmail.com= > wrote:
> On Tue, Jan 12, 2010 at 12:45 PM, Evan Phoenix <evan@fallingsnow.net> wrote:
>>
>> 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 barri= ers. To port to MRI, you'd have to rewrite most of the internals to use= write barriers, and then no extensions would work because the GCs are accu= rate only (no conservative stack scanning), and they require the ability to= move objects.
>>
>
>
> 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 =A0VS =A0 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




--

---
Gon= =E7alo S. Silva
http://goncalossilv= a.com

im: goncalossil= va@gmail.com
skype: goncalosantaremsilva
twitter: http://twitter.com/goncalossilva
--00032555a19a1e86af047d2387c0--