From: Charles Oliver Nutter <charles.nutter@...>
Date: 2007-12-27T07:03:12+09:00
Subject: Re: Some Ruby 1.9 loose ends to tie up

Paul Brannan wrote:
> On Thu, Dec 27, 2007 at 05:49:19AM +0900, Charles Oliver Nutter wrote:
>> If it turned out to be a use case that broke some code someone was 
>> concerned about, the fix in JRuby would be to also look for "send" calls 
>> to "binding" and friends. Another option would be for JIT mode...if such 
>> calls are actually calling binding and friends, we would track that and 
>> compile them differently later. So far, neither change has been necessary.
> 
> Or, if it were truly a keyword and not a method, it wouldn't be possible
> to call #binding on an object (nor to alias it).

Quite...or at the very least, it wouldn't invoke "binding" as we know it 
today, and wouldn't be a problem.

>>> Which variables would need to be placed on the heap in this case?
>> Only variables that need to be accessible across call boundaries would 
>> have to be on the heap. So in this case, b could be on the stack (or in 
>> a register) while o would go on the heap.
> 
> The code as it would be outside irb:
>   o = Object.new
>   b = o.send(:binding)
>   p eval("o", b)
> 
> I think this is a bad example, since I'm making a call to eval.  Don't
> both o and b need to be accessible across call boundaries?  (or are you
> doing some sort of analysis on the string passed to eval?)

Sorry, I should have been more clear. The only times we can determine 
statically that specific variables need to be heap-based is when we're 
using blocks:

a = 1
b = 2
1.times { b = 3 }

Here, if not for procs becoming bindings, we could statically determine 
that only b needs to be heap-based, thus avoiding heap scope overhead 
for the "a" variable. Since variables being modified from within a block 
is much less common than using scope-local variables, this could 
represent a good general-purpose performance boost...especially for 
methods with lots of nested blocks that aren't modifying a lot of shared 
variables.

For eval, since we can't know in advance, we have to assume all 
variables and all frame/scope state must be available. So JRuby removes 
all optimizations in the presence of eval.

- Charlie