On 7/17/06, Ola Bini <[EMAIL PROTECTED]> wrote:
You've more or less got it. There's only a few differences in what I think we'll end up doing:
- Rather than allocating a frame per-call, as you do with new IRubyObject[1], there would be a single per-thread stack (implemented as an array/list) from which we'd allocate our frame. This eliminates one more object allocation per-call. Where today we instantiate a Frame, which instantiates a Scope, which instantiates an IRubyObject[] that contains the vars, we will then just index into that stack. Less memory overhead, less object allocation overhead per-call, and a less garbage to collect.
int base = threadContext.allocateFrame(numOfLocals);
threadContext.getStack()[base + 1] // accesses second indexed variable in the the locals
- Blocks would then only need to know one thing, really, to access local vars: the position of those vars in the stack.
- I haven't figured out the best way to handle procs and lambdas yet; they introduce some interesting side effects. Currently, procs and lambdas are no worse cost than blocks are...but blocks should be cheap, like they are in Ruby. I need to understand the scoping of proc/lambda as regards local vars a bit better before I come up with anything.
- You are correct about "real closures" being an issue...I don't have a good answer for that yet, but I think sacrificing real closure speed to make simple blocks faster would be a big win...blocks are used *so much* more than real closures like proc and lambda.
This is all still a bit theoretical, but I feel like eliminating per-call allocations in favor of a thread-local stack machine would save us a lot of overhead.
-- Let's see if I understand more or less how this would work. The block
closures seem to be more or less like how lexical variables in Lisp are
usually compiled.
You've more or less got it. There's only a few differences in what I think we'll end up doing:
- Rather than allocating a frame per-call, as you do with new IRubyObject[1], there would be a single per-thread stack (implemented as an array/list) from which we'd allocate our frame. This eliminates one more object allocation per-call. Where today we instantiate a Frame, which instantiates a Scope, which instantiates an IRubyObject[] that contains the vars, we will then just index into that stack. Less memory overhead, less object allocation overhead per-call, and a less garbage to collect.
int base = threadContext.allocateFrame(numOfLocals);
threadContext.getStack()[base + 1] // accesses second indexed variable in the the locals
- Blocks would then only need to know one thing, really, to access local vars: the position of those vars in the stack.
- You are correct about "real closures" being an issue...I don't have a good answer for that yet, but I think sacrificing real closure speed to make simple blocks faster would be a big win...blocks are used *so much* more than real closures like proc and lambda.
This is all still a bit theoretical, but I feel like eliminating per-call allocations in favor of a thread-local stack machine would save us a lot of overhead.
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
