[pypy-dev] Saving and reloading JIT optimizations

[Zooko O'Whielacronx]

Dear Armin Rigo:

Thank you for your reply.

On Sat, Aug 20, 2011 at 3:39 AM, Armin Rigo <arigo at tunes.org> wrote:
>
> So no, there is no way at all to make this idea work in general; you
> can only do hacks that hopefully don't break too often.  I am not
> interested :-)

I also wouldn't be interested in techniques that sometimes resulted in
incorrect behavior.

But I still don't understand why you say this can't work in general.
If you don't mind explaining it a little more I would appreciate it.

The behavior of a program is a deterministic function of its source
code, right? So if the source code (*all* of it -- everything that
gets imported and executed at any point during the run of the program)
is identical, then the behavior will be identical, and then re-using
compiled code from previous runs would always yield a correct result.
Am I still on track so far?

So then suppose you have a copy of the source code of the program
(*all* of it), and you make one change, such as changing a constant
from 42 to 43. Now can't you still safely re-use *some* of the
previously compiled code to run the new program? Or perhaps not. Since
we are using JIT techniques to take advantage of as much knowledge as
we can, the we may use the knowledge that the constant is 42 to
compile all of the rest of the program differently, resulting in
compiled code none of which can be safely reused.

That is an interesting prospect to consider. It underscores how
powerful (at least potentially) JITting can be.

But, I still think there are probably some boundaries where you can
know for sure that the change cannot have invalidated some of the
compiled code. For example, what about code that you compiled before
you imported the module that had the changed constant? That code must
surely still be valid. Are there are other such boundaries that allow
the safe re-use of compiled code?

Thank you for your time in discussing this idea, and also by the way
thank you for contributing to the PyPy project!

Regards,

Zooko