Re: Non-overridable and non-redefinable methods

--- SASADA Koichi <[e-mail]> wrote:

> Hi,
> 
> Florian Growrote:
> > I'd propose doing it similar to YARV. Optimize 1 + 2, but
> only if you 
> > clearly see a Fixnum.freeze at the beginning of the file.
> 
> YARV doesn't inline Fixnum#+.  If Fixnum#+ is redefined, YARV
> invoke 
> redefined function (same as current Ruby interpreter).   ...
> In the 
> future version.  I have already inserted redefine check code,
> but not 
> write redefine notify code (in rb_define_method()).

Thank you for responding as what I'm talking about is directly
related to what you are doing.

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.

...

> 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.

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.

> (But current ruby interpreter inlinie "/foo/ =~ expr" ...)

Interesting:

class Regexp
  alias :old_compare :=~
  def =~(s); puts("matching");old_compare(s);end
end

> /foo/ =~ "foobar"
=> 0
> /foo/.send(:=~, "foobar")
matching
=> 0
> (/foo/) =~ "foobar"
matching
=> 0

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

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

> Of course, I want to add restriction to Ruby's specification
> :) 

especially for many of the core methods!

> 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).


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com