I did some mocking up of a method with a block using some of the models Ola and I kicked around earlier in the thread. They mostly hold up, except for a few issues:
- returns from within a block complicate things a fair bit. Since we would deepen the stack for the method to which we call the block, and then deepen it again for the block itself, a return at that point (which should escape the original method) would have to do the whole "return sled" exception trick. That's doable, but it adds quite a bit of complexity.
- It's not something we could switch to wholesale in the short term. Our whole call stack needs to be ripped up and refactored, and I think refactoring it in the current form would be easier than introducing this new compiled model. We'll also get significant performance improvement from that refactoring process anyway, so tying it to the compiler is not crucial right now.
- Tom and I are debating back and forth what the call chain should actually look like, and that needs to be somewhat settled before any of this begins. It occurred to me today that the complexity surrounding block management (the whole block and iter stack thing) only exists in C ruby because blocks were a concept tacked-on to the original non-block Ruby
pre-1.6. We're not exactly sure what the right model is, but I think it's safe to say that we can rip out almost all that complexity and still support all the current Ruby block semantics. Even if there's one or two areas that don't work as expected, any thunking would only be a minor hit.
Tom is currently trying to wrap up some work on making block scoping information static, rather than generated per-call. That promises to simplify block calls quite a bit. I'm going to mock up a few options for always passing blocks as an argument, allowing us to completely eliminate the iter/block stack nonsense. Tom and I have both been working on simplifying or eliminating the other remaining stacks in the thread context. All told, with each piece per-call overhead is reduced significantly, and that still seems to be where most of our performance problems occur.
Expect to see some broader-ranging patches and commits coming in the next week or two. My MultiStub work is the first part of that, and Tom's block scoping stuff will probably come next.
--
Charles Oliver Nutter @
headius.blogspot.com
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________
Jruby-devel mailing list
Jruby-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/jruby-devel
|
