On 7/15/06, David Corbin <[EMAIL PROTECTED]> wrote:
On Saturday 15 July 2006 18:06, Charles O Nutter wrote:
> The compiler I'm working on at present is a full-on Java bytecode compiler
> using ASM. An AST visitor traverses the tree and generates Java bytecodes
> for each type of node. The resulting code looks, in general, like what we
> implement for builtin methods written in Java by hand. There will be a
> large number of methods that should be 100% compilable by this compiler,
> and by compiling they'll escape all the overhead of interpretation.
> However, I don't yet have a good strategy for instantiating blocks, since
> in Java no method's code can access the state of another method's code.
> This compiler is also fairly dependent on the current method-call and
> variable-scoping semantics, which are slated for redesign.
Think anonymous classes. Of course, these are not REALLY accessing the state,
but they create the illusion, and if they can do it, you can do it.
However, once we return to the original method, those fields have to actually have been modified. Further, if the block is turned into a proc or lambda all bets are off...we need to memoize the creating method's state and keep it around for the proc or lambda to use later.
I have thought a bit about anonymous classes for blocks (since they really are just closures) and have some thoughts on how we could use them:
- There's *no way* to have Ruby local vars be Java local vars and pass a block elsewhere that can modify them. It's simply not possible. We can memoize those vars, making them final for an inner class, but then we can't actually modify them. Given this truth...
- Local vars in Ruby code compiled to Java *must* be maintained in a separate data structure.
- Currently, they are maintained in a Scope object, where there's one Scope per call Frame. This is a bit inefficient at the moment, requiring multiple structures when one would do.
- As a simple alternative, we might maintain local vars as an array per method invocation (which is basically the same thing we do in Scope, but lighter-weight and not bound to the existing runtime). If there are ten local vars in a method's lifetime, we have ten slots in that array. evals could cause new arrays to come into being, and we'd need to grow the array. However, we could easily pass a final reference to this array of values to an inner class "block" when passing it off. Later invocations could then directly access and modify those values.
Now this is a fairly simplistic view of how local variables are accessed from blocks, but it does illustrate that it's possible for us to achieve very similar behavior with pure Java code. Tying this into the rest of the runtime and into proc/lambda instantiation will complicate things, however, so with our current work on improving call logic, we'll take "blocks-in-Java" slow for now.
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Jruby-devel mailing list Jruby-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jruby-devel
