[pypy-dev] can_enter_jit - what is it and did something change?

[Armin Rigo]

Hi Yuriy,

See the old explanation about our JIT here:
rpython/doc/jit/pyjitpl5.rst.  What changed from this old explanation
is that if no can_enter_jit is found in the source code, one is
automatically inserted just before the jit_merge_point.

About your other questions:

> - Is it correct to not have any _user_ code run between can_enter_jit and jit_merge_point calls but have some _interpreter_ code there? Error message says that there should be _any_ code between them which seems hardly possible.

There should not be any code that doesn't fully constant-fold away.
You can have some function returns, and maybe close a loop that says
"while True".  You cannot close a loop that says "while more
complicated condition".

If this condition seems unclear to you, you can also restrict it to:
you should compute a flag, "needs_can_enter_jit", during one bytecode,
defaulting to False.  Then your interpreter looks like:

needs_can_enter_jit = False
while some_condition:
    if needs_can_enter_jit: jitdriver.can_enter_jit(...)
    jitdriver.jit_merge_point(...)
    needs_can_enter_jit = False
    ...   # sometimes set needs_can_enter_jit to True

where the two sets of arguments must be exactly identical (and not
include 'needs_can_enter_jit').

> - Why do we need to place this hint in the beginning of the next iteration of the loop but not at the end of current iteration? It would seem logical to say "you might want to compile from here (start of the loop, one of jit_merge_points) and here (end of the loop, can_enter_jit hing) if you like".

I'm not sure to understand the distinction.  The end of one iteration
of the loop should be exactly the same as the start of the next
iteration, unless there is code between the two -- which is disallowed
by the previous rule.

> - Would it be more beneficial to analyse user code and provide can_enter_jit hint only for real loops instead of all backward jumps?

It's a bit pointless.  As I said, can_enter_jit is only an
optimization: you make the JIT tracing a little bit faster by not
calling it repeatedly before every single jit_merge_point.  You could
spend efforts and make it even less common using bytecode analysis,
but you're hitting diminishing returns very quickly imho.


A bientôt,

Armin.