From: Eric Mahurin <eric_mahurin@...>
Date: 2005-08-18T07:28:09+09:00
Subject: Re: Prototype-based / Ruby question

--- Ron M <rm_rails@cheapcomplexdevices.com> wrote:

> Eric Mahurin wrote:
> > 
> > The biggest problem I have with being able to
> add/remove/modify
> > methods of an object (using a meta class or directly in the
> > object's class) is the future of optimization in Ruby. 
> Adding
> > methods may not cause too much of an issue, but modifying
> them
> > sure could.  For example:
> > 
> > i = 0
> > i += 1
> > 
> > In this case, Ruby could recognize that i is always a
> Fixnum
> > (or a Bignum depending on how smart it is).  If it knew
> exactly
> > what "+" was for a Fixnum, it would be able to in-line that
> C
> > call (in this hypothetical Ruby compiler).  Unfortunately,
> "+"
> > could be anything since it can change at run-time.
> 
> Seems like the same issue Java and Self compilers have
> when new classes are loaded.
> 
> There are Java compilers that optimize method calls by
> inlining them, and then "dynamically deoptimize" those
> if a derived class that changes the meaning of that
> inlined code is loaded.

This is not directly what I'm talking about, but related.  You
aren't changing already defined classes (or the class of an
object) in this case.  A derived class is overriding a method
definition of a parent - not changing the parent.

In Ruby, I think this would apply to Object and Kernel methods.
 In Java, you statically type variables to a given class (or
any class derived from that one).  You could inline the method
of the parent class, but if a derived class uses overrides that
method, you'd have to "deoptimize" as you say.

In Ruby, all variables are just an Object, so I think only
methods in Object and Kernel apply to this topic.  For some
methods, I don't see why you'd want to override methods in
Object.  Take for example Object#equal.  If this wasn't
overridable, you could replace every call to equal with a
simple pointer comparison - bypassing method lookup and the
call overhead.  I guess you'd need some "final" concept for a
method.


> Here's one paper on such dynamic de-optimization:
>   
>
http://research.sun.com/self/papers/dynamic-deoptimization.html
> 
> 
> Isn't the real challenge your hypothetical "could recognize
> that i is always a Fixnum" condition.  If the ruby compiler
> could do this, couldn't that same logic recognise that it is
> always a pristine, unmodified Fixnum.  Knowing the type
> sounds
> to me like the hard part of the problem. IIRC Lisp added
> optional type declarations to the language that you can
> use inside performance critical areas like tight-loops.

Yes, this is a hard problem.  I'm not sure how much of the time
you could detect the exact class.  To really take advantage of
this the compiler would need to unroll the method calls such
that each time a method is called with a different set of
classes for the arguments, you'd compile a new copy of that
method just for those classes.

Even after you figure out how to do this, you still won't be
able to determine whether Fixnum is "pristine" at compile-time,
because the methods of Fixnum can change at run-time.



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs