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

[Hakan Ardo]

On Sat, Mar 12, 2011 at 8:34 PM, Antonio Cuni <anto.cuni at gmail.com> wrote:
> 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.

We should probably log the VirtualState together with the produced
loops and bridges. That would allow us to see how they differ when a
new version of a loop is traced. There are __repr__ methods I've been
using for that while debugging. They might need some rpythonizing to
translate though---

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

Maybe, I've not had the chance to look into any details yet. I'll do
that tomorrow...

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

So if it's the same loop traced several times they should all have the
same preamble, and the preamble would have two bridges leading to the
two second versions of the loop. The preamble and it's two bridges
should end with different VirtualState's. The loops should  be
specialized to the different VirtualState's, but if the VirtualState's
are similar enough (but not equal) they might consist of the exact
same operations.

If there are 3 preambles for the same loop, there is a bug somewhere...

-- 
Håkan Ardö