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

[Hakan Ardo]

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.

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).

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...

On Thu, Mar 10, 2011 at 6:22 PM, Antonio Cuni <anto.cuni at gmail.com> wrote:
> On 10/03/11 16:21, Antonio Cuni wrote:
>
>> I did a bit of manual binary search and discovered that the test started
>> failing between r42273:b8bb5d085684 and r42305:3fe93dd500bd. Looking at the
>> commit, it seems that the only one relevant to the problem is
>> r42305:3fe93dd500bd, i.e. the merging of jit-virtual_state.
>
> I confirm that the problem is the merging of jit-virtual_state: I just tried
> the revision just before the merge, and the test passes.
>
> ciao,
> Anto
>



-- 
Håkan Ardö