Well I would think if JRuby can figure out on its own if the NOFRAME optimization is safe or not then would I really need to tell it myself? Maybe this is an optimization that will be enabled for everything eventually? I would think these pragmas would only be used if there was no way for the compiler to decide if an optimization was safe or not. This is really interesting stuff, I wonder how much of a speed boost could be made with little hints like this?
Joe On Mon, Apr 13, 2009 at 10:51 PM, Charles Oliver Nutter < [email protected]> wrote: > Joseph Athman wrote: > >> This looks pretty good to me. So basically if a __NOFRAME__ local >> variable is found inside a method then JRuby will make its enhancements? >> > > That's right, though currently it won't make enhancements that its own > static inspection detects are unsafe. In other words, if you say __NOFRAME__ > = true, but then proceed to call eval or use $~, we'll save you from > yourself. Would it be better for it to be a "hard" pragma that lets you blow > up if you want to? > > Have you talked with the Rubinius or IronRuby guys about these ideas at >> all? I'm not really sure if these optimizations are implementation specific >> or not, but maybe clues could be added that more than just JRuby would >> understand. >> > > I've talked a few times with Evan about this. Rubinius already has one > enhancement I'd like to add, an "asm { }" block where you can put raw RBX > ASM. In our case, it would essentially be BiteScript within that block, and > you'd be emitting JVM bytecode. Given that, you could implement almost any > hack you wanted, since you'd essentially be adding raw JVM bytecode into the > compile sequence. > > Outside of this, we haven't talked much about pragmas. > > Could you explain this a little more? A compile plugin sounds a little >> scary to me. >> > > The basic idea is that you'd provide plugins to be loaded when running > "jrubyc" and they'd modify compilation by hooking into the process. I > haven't given it a whole lot of thought, but I'd like a way to be able to > modify the compile phase without directly modifying the compiler. > > > - Charlie > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
