From: Evan Phoenix Date: 2011-10-07T14:19:07+09:00 Subject: [ruby-core:40017] Re: 2.0 feature questionnaire --20cf30780cf430491d04aeae8595 Content-Type: text/plain; charset=ISO-8859-1 See below. On Sun, Oct 2, 2011 at 3:52 PM, Urabe Shyouhei wrote: > Oops, I was mentioned. > > (10/02/2011 05:34 PM), Jeremy Kemper wrote: > >> |3. MVM, with inter-vm message passing. > >> > >> I have not decided yet, but since MVM requires incompatible changes to > >> C API, so we might pend it to Ruby 3.0. > > > > I understand @shyouhei's branch is backward compatible for extensions > > that don't use MVM features. > I did quite of work into getting MVM working on Rubinius and ended up stopping development because I can't see how you can rectify it with how most C extensions are written. Specifically, most extensions use static VALUEs and IDs variables. To make matters worse, extensions commonly store VALUE's for Modules and Classes in static variables without calling rb_global_variable() (This is itself a latent bug that almost no one hits because how the MRI GC works). Any C extension that uses any static VALUE or ID will crash the whole process very quickly, meaning that most existing C extensions are not compatible with MVM UNLESS they are recoded to remove static VALUEs and IDs. I haven't seen @shoyuhei's branch in a while, how is this issue dealt with? > > > > I think it's another case where the benefits outweigh the cost. > > > > C extensions can gradually update for MVM compatibility. > > > > Otherwise, we wait for Ruby 3.0 and we confront the same problem. Then > > we pend it to Ruby 4.0 for the same reason, because it requires > > incompatible changes to the C API. > > It seems the definition of "API" differs between you. > > My branch is merely compatible in C source code layer. That is, in > short, binary incompatible. You have to recompile all the existing > extensions. If you can accept this situation, yes, the source codes > themselves are compatible. > > --20cf30780cf430491d04aeae8595 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable See below.

On Sun, Oct 2, 2011 at 3:52 PM= , Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
Oops, I was mentioned.

(10/02/2011 05:34 PM), Jeremy Kemper wrote:
>> |3. MVM, with inter-vm message passing.
>>
>> I have not decided yet, but since MVM requires incompatible change= s to
>> C API, so we might pend it to Ruby 3.0.
>
> I understand @shyouhei's branch is backward compatible for extensi= ons
> that don't use MVM features.
=A0
<= span class=3D"Apple-style-span" style=3D"font-family: Helvetica; font-size:= 13px; ">
I did quite of work into getting MVM working on Rubinius and = ended up stopping development because I can't see how you can rectify i= t with how most C extensions are written.

Specifically, most extensions use static VALUEs and IDs variables. To m= ake matters worse, extensions commonly store VALUE's for Modules and Cl= asses in static variables without calling rb_global_variable() (This is its= elf a latent bug that almost no one hits because how the MRI GC works).

Any C extension that uses any static VALUE or ID will crash the whole p= rocess very quickly, meaning that most existing C extensions are not compat= ible with MVM UNLESS they are recoded to remove static VALUEs and IDs.

I haven't seen @shoyuhei's branch in a while, how is= this issue dealt with?=A0=A0
=A0
>
> I think it's another case where the benefits outweigh the cost. >
> C extensions can gradually update for MVM compatibility.
>
> Otherwise, we wait for Ruby 3.0 and we confront the same problem. Then=
> we pend it to Ruby 4.0 for the same reason, because it requires
> incompatible changes to the C API.

It seems the definition of "API" differs between you.

My branch is merely compatible in C source code layer. =A0That is, in
short, binary incompatible. =A0You have to recompile all the existing
extensions. =A0If you can accept this situation, yes, the source codes
themselves are compatible.


--20cf30780cf430491d04aeae8595--