Hi,

Eric Mahurin wrote:
> It looks like from the code you presented, all of the checks
> are made at runtime every time you invoke the method.  Do you
> plan to move as much of this checking as possible to
> compile-time?  In this example (with the current language) if
> you could somehow figure out that the object you are sending +
> is a Fixnum (maybe you might have to say Fixnum/Bignum) and
> there was a previous Fixnum#freeze, just in-line the current
> definition of Fixnum#+.  You could do the same with any method
> of any class if you can do the same.

All checks were done at runtime.  And yes, YARV process Bignum 
correctly.  Please check YARV source code.  Only one conditional branch 
doesn't perform serious performance decrement.

>>Re-compile inlining code if someone redefines some special
>>methods, has 
>>some difficulty.  If re-compiled function was already called,
>>you must 
>>replace return address of method like "on stack replacement".
> 
> 
>>BTW, I hate redefinable method for VM performance (of
>>course!).  But 
>>redefine method is power of language (flexibility,
>>refrectionability). 
>>IMO, if you restrict Ruby's language specification, it will
>>be Ruby--. 
>>I'm trying to beet this "bad specification for performance"
>>with VM 
>>implementation technique (not change specification).
> 
> 
> My guess is that the performance (speed and memory) of a
> redefinable method will never reach what could be done with a
> non-redefinable method.
> 
> What do you think about having a way to specify non-redefinable
> methods, only try to inline those, and tag many of the core
> methods that make no sense to redefine (i.e. Regexp#=~,
> Fixnum#+) as non-redefinable?  This way you'll leave the power
> of being able to redefine methods in the language, but you can
> still optimize those methods marked as non-redefinable.

I think __send__ and __id__ should be non-redefineable method.  don't 
think others (because of the language power).

> Any opinion about the other topic I had - non-overridable
> methods?  I'm mainly talking about stuff in Object - __send__,
> __id__, equal?, nil?, etc.  If you knew these couldn't be
> overridden (in a derived class - all other classes) or
> redefined, you could in-line these as soon as you saw them. 
> Much easier than the Fixnum#+ case discussed above where you
> have to figure out that the object is always a Fixnum.

I've abandoned static ruby program analysis :P

> 
> Obviously there should be a restriction to not redefine
> Regexp#=~ because you'll get wildly inconsistent behavior
> (sometime use original def and sometimes new).

Yes.

> I wonder how many other core methods are inlined like this -
> even in ruby code.

only one (which I know).  I think it's bad implementation.


>>Especially Evil Eval!
> 
> 
> I discussed that one a while back too.  I looked through the
> stdlib code and found that everywhere eval is used, it is used
> to define methods where you want to propagate local variables
> as constants in those methods.  I proposed that there be a way
> to replace local variables in a Proc that are defined outside
> the Proc with there current values.  I think this would allow
> 99% of the evals to be replaced with define_method on a Proc
> that has the local variables replaced.  I think this would be
> much better for compilers and VMs and as a side benefit make
> the code more readable (rather than having code in strings).

I often use eval (I love the "eval" in ruby programming :P) to do 
inspection or something else.

-- 
SASADA Koichi at atdot dot net