ideas for a JIT optimizer

[Roger Pack]

Currently I am thinking that an optimizer that takes

class A
def one_thing
calls_another 3
end
def calls_another a
a.to_s
end
end

and converts it to C, such that one_thing calls another *in c* would be
a good JIT.

ex:
VALUE
one_thing_in_c(VALUE self) {
return calls_another(NUM2FIX(3));
}

VALUE to_s = rb_intern("to_s");
VALUE calls_another(VALUE self, VALUE in) {
return rb_funcall(in, to_s);
}

Any thoughts on this? Ideas? Suggestions?
This seems to be the next step for ruby2cext (which almost does this,
but not quite).
Thanks much.
-=r

 

[Charles Oliver Nutter]

Currently I am thinking that an optimizer that takes

class A
=C2=A0def one_thing
=C2=A0 =C2=A0calls_another 3
=C2=A0end
=C2=A0def calls_another a
=C2=A0 =C2=A0a.to_s
=C2=A0end
end

and converts it to C, such that one_thing calls another *in c* would be
a good =C2=A0JIT.

It would be *one way* to jit, but it would not allow for polymorphism
(multiple target types providing the same method) or any redefinition.
Nor would it easily allow for methods to be defined at runtime, so
you'd need to make sure both methods exist and choose to statically
bind them (setting that binding in stone) for all time. In this case,
where you're doing a "self" call, as long as there's no subclass and
no method changes at runtime, it's probably ok. But of course you
don't know if it will stay that way forever.

- Charlie