From: Charles Oliver Nutter <charles.nutter@...>
Date: 2008-12-05T12:58:59+09:00
Subject: [ruby-core:20356] Re: Behavior: autoload calls rb_require() directly

Yes, deoptimization is the hard case; compiling, recompiling, even 
inlining are easy. We will certainly look at iterative compilation, but 
without deopt we can't get far.

The more logical thing for JRuby is to just line all the pieces up so 
that the JVM can optimize it. The JVM (OpenJDK's HotSpot, at least) 
*does* do deopt, profiled optimization, inlining, and iterative 
compilation. At this point we will slowly move Ruby code closer and 
closer to an ideal optimizable path for the JVM, and performance will 
continue to improve with every release.

Tomas Matousek wrote:
> Except for the frames that are already on stack... that's not so easy.
> 
> Tomas
> 
> -----Original Message-----
> From: Paul Brannan [mailto:pbrannan@atdesk.com]
> Sent: Thursday, December 04, 2008 7:26 PM
> To: ruby-core@ruby-lang.org
> Subject: [ruby-core:20354] Re: Behavior: autoload calls rb_require() directly
> 
> On Fri, Dec 05, 2008 at 09:56:19AM +0900, Charles Oliver Nutter wrote:
>> All these optimizations are predicated on arriving at a static view of
>> the world at some point during execution. The ability to redefine
>> Fixnum#+, for example, means that we'll always need (at minimum) a guard
>> against + being overridden. If it's possible to eliminate the need for
>> those guards, our the potential for a static worldview expands, the
>> generated code gets smaller, and performance increases.
> 
> Instead of using guards you can recompile the world if someone ever
> does override Fixnum#+.  I guess this means slightly higher memory
> consumption, since some representation of the function needs to be kept
> around just in case.
> 
> Paul
> 
> 
> 
>