On Mon, Sep 15, 2003 at 11:19:22AM -0400, Dan Sugalski wrote:
> Changing a function from pure to impure, adding an overloaded operator, or
> changing the core structure of a class can all result in code that needs
> regeneration. That's no big deal for code you haven't executed yet, but if
> you have:
>
> a = 1;
> b = 12;
> foo();
> c = a + b;
> but if foo changes the rules of the game (adding an overloaded + to a or
> b's class) then the code in that sub could be incorrect.
>
> You can, of course, stop even potential optimization once the first "I can
> change the rules" operation is found, but since even assignment can change
> the rules that's where we are right now. We'd like to get better by
> optimizing based on what we can see at compile time, but that's a very,
> very difficult thing to do.
Sorry if this is a crack fuelled idea, and sorry that I don't have a patch
handy to implement it, but might the following work:
0: retain the original bytecode
1: JIT the above subroutine as if a and b remain integers
However, at all the "change the world" points
(presumably they are de facto sequence points, and will we need to
take the concept from C?)
put an op in the JIT stream "check if world changed"
2: If the world has changed, jump out of the JIT code back into the
bytecode interpreter at that point
I fear that this would mean that the JIT wouldn't just have to insert lots
of "has world changed" ops, but also an awful lot of fixup code that
nearly never gets executed; code to stuff values back from processor
registers into parrot registers.
Then again, as this code is rarely executed and isn't speed critical
(after the world has changed you're likely to be in the the switch core,
which isn't slow) maybe the fixup would actually be better as densely
compressed special bytecode instructions on which processor registers to
save where in the parrot interpreter struct.
Effectively the JIT code would have an escape hatch instruction for every
debuggable position in the original parrot source. This seems expensive on
space, but is the only way I can think of to implement JITting of (say)
arithmetic on loops where there are calls midway which could tie/overload/
whatever the very variables used in the loops.
Nicholas Clark
