[pypy-dev] problem after merging of jit-virtual_state

[Antonio Cuni]

Hi Hakan,

On 12/03/11 19:25, Hakan Ardo wrote:
> Yes, this is probably the VirtualState checking. It will retrace a
> loop whenever the VirtualState at the end of a bridge differs from the
> VirtualState at the beginning of the compiled trace (any of the
> compiled traces). This might indeed produce an identical trace if we
> are unlucky, but the idea is that this should only happen rarely.

ok, that's clear. So, hopefully this particular example looks a bit bad, but
in general it should not be an issue. It'd be nice to have a way to check this
thesis, but I agree that it's a bit hard.

> This is because the VirtualState  at the beginning of a trace is the
> state of all the OptValue of the inputargs produced during the
> optimization of the trace. This does not have to be the most general
> state for which the trace is usable (which would be hard to calculate
> I'm afraid).

so, if I understand correctly, this is what happens:

1. we trace, optimize and compile loop A

2. after a while, we trace, optimize a compile a bridge B which then jumps
back to A; by chance, the bridge looks the same as the loop

Am I right?

> A few cases that would (most likely) result in identical traces are
> salvaged in NotVirtualInfo._generate_guards by producing some extra
> gurads at the end of a bridge to make the VirtualState there match the
> VirtualState of a compiled trace. This is however only done if the
> guards would (most likely) not fail for the traced iteration.
> 
> I'll look into what's happening in this particular test...

I just did a quick check because I'm in a hurry, but from what I see we get
three actual *loops*, not bridges.

ciao,
Anto