Re: Some Ruby 1.9 loose ends to tie up

SASADA Koichi wrote:
> The reason why I commit Proc#binding is that some of applications
> needs this feature such as template engine.  Some people asked me to
> add it and matz admit it.  It seems reasonable reason.

The only thing it gains you is that you don't have to explicitly pass in 
a binding. If those template engines just required you to pass in a 
binding, there would be no problem removing Proc#binding.

But I digress...it's a fun feature, and some people want it. We'll 
continue to support it, and people will pay a performance penalty as a 
result. Those are the tradeoffs we all learn to accept. :)

> I can't say anything that Proc#binding should be or should not be
> removed for JRuby's performance.  As a ruby user, I think it should
> be supported.  As a VM implementator, I think it (and other dynamic
> features) should be vanished.

Ok, I understand :)

> On optimization aspect, I believe that we can't optimize environment
> if Kernel.binding and Kernel.eval are normal methods.

We pretend that they are keywords and always deoptimize when calls to 
"eval" or "binding" or others are present. See below.

> But on JRuby, just now I understand that JVM stack holds (will
> hold?) ruby's environment (local variables and so on).

JRuby "pretends" that eval, binding, and other methods are keywords, 
since the only cases where they won't be their normal selves is if 
they're aliased (which nobody does). Other methods in the system have 
similar treatment. By assuming that "eval" always means eval, we can 
optimize specific scopes to use Java stack for local variables.

If eval, binding, etc, or a block are present, JRuby falls back on a 
heap-based structure. If procs could not be bindings, we could fall back 
for only specific variables, leaving the others on the stack (a 
technique that IronRuby and XRuby use, but which will break in the 
presence of proc-as-binding).

- Charlie