[rowanG077]

I see. This doesn't look like a Futaruma Projection to me. What PyPy does is run a python program under their own RPython based interpreter. Then it uses a tracing JIT to JIT the RPython based interpreter. There is no PE going on. No residual specialized program is created.

The first Futaruma Projection would be if PyPy would specialize the interpreter based on the python program yielding an executable.

[samth]

That's exactly what PyPy does do. You get a specialized version of the interpreter which is specialized to the particular program.

[rowanG077]

No you don't get that. A tracing JIT is not capable of producing an executable like that under normal circumstances. If a certain path is not taken during execution it might not be compiled at all. The point of the first futurama projection is that you get a fully runnable executable that is semantically equivalent to running the original program in the interpreter. A JIT only produces what it sees during execution. I guess it might be possible if you carefully run your program with inputs that exhaust every possible path.

[jhgb]

Clearly PyPy has to produce executable code if it wants to jump into it. The CPU wouldn't understand if it were asked to jump into something that isn't executable code.

> The point of the first futurama projection

...was to delight viewers with what would turn out to be a wonderful pilot episode?

[rowanG077]

It produces executable code ad hoc based on the dynamic environment. Not an executable. That's not the same thing.

[jhgb]

I don't see how the frequency or laziness of the process makes a meaningful difference. It takes an interpreter, evaluates it with partial information (like, "type of x is integer"), and delays the rest till the execution is possible with the remaining information (like, "x is 7").

[pjmlp]

An pure executable no, but a JIT cache certainly.

Used across Java implementations, and modern Android.