Nicholas Clark writes:
> 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
No, I think Parrot will still only JIT I&N registers. Optimization
includes way more than just JIT.
I was thinking, the compiler could emit two functions: one that works
on regular PMC's, and one that works with I registers. The latter would
then be JITted as usual, and JIT doesn't need to do anything special.
The focus here, I think, is the following problem class:
sub twenty_five() { 25 } # Optimized to inline
sub foo() {
print twenty_five; # Inlined
&twenty_five := { 36 };
print twenty_five; # Uh oh, inlined from before
}
The problem is we need to somehow un-optimize while we're running. That
is most likely a very very hard thing to do, so another solution is
probably needed.
Luke
