From: Ron M <rm_rails@...>
Date: 2006-07-05T09:21:00+09:00
Subject: Re: Huge performance gap

Charles O Nutter wrote:
> On 7/1/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
>> how is this performance data available significantly different 
>> from that made transparent by gcc/gprof/gdb/dmalloc/etc -
>> gcc can encode plenty of information for tools like these 
>> to dump reams of info at runtime.
...
> Ahhh, venturing into a domain I love talking about.
> 
> Runtime-modification of code is exactly what sets the JVM apart from static
> compilation and optimization in something like GCC. 

An even more interesting example of what JIT compilers
can do is "dynamic deoptimization" [1,2].

A JIT compiler can optimistically perform some very aggressive
optimizations and undo them later on if something (like a new
class being loaded, or a dynamic class modified) would make
these optimizations no longer valid.


One example is inlining of virtual methods or methods from
dynamic classes.

A VM can optimistically treat virtual function calls as normal
calls and even inline them -- and later if it notices that
someone did create a derived class or modify the dynamic
class it could de-optimize those function calls when the
class is modified.

I think this could be *extremely* interesting in as dynamic
a language as Ruby.

   Ron

[1] http://research.sun.com/self/papers/dynamic-deoptimization.html
[2] http://portal.acm.org/citation.cfm?id=143114&dl=ACM&coll=portal&CFID=15151515&CFTOKEN=6184618