Idea: Super Looper Side Trace about raptorjit

[javierguerragiraldez]

i like this; but is that super trace supposed to actually contain a copy of (some of) the IR of the parent trace, or is it just an abstract construct for better optimizations? if it's a copy, then the exit from the parent trace would need to jump to middle of the new (super) trace. if it's abstract, then i don't see how the loop optimization would work.

hum... thinking a little on this; the current loop otimization is the only case of a jump to the midpoint of a trace. not hard to admit because its from the end of the same trace, so it's well contained. but this kinda opens the door to having a loop directly jump from the end of the side trace to the middle of the parent trace. might be possible if the snapshot history is carefully taken care of. maybe the (abstract?) copy of parent's IR would precisely help with that

[lukego]

@javierguerragiraldez Thanks for playing along. Let's see if we can tease this picture out.

Let me throw some ascii art out. Suppose we have a program like this:

while true do
  A()
  if root then
    B()
  else
    C()
  end
end

Then today it would compile to a looping root trace and a side trace like this:

ROOT:     SIDE:
A.........
B         C
LOOP:     ->ROOT
A'
B'
->LOOP

And it seems to me that with this change we would make this instead:

ROOT:     SIDE:
A.........
B         C
LOOP:     SLOOP:
A'        A'
B'        C'
->LOOP    ->SLOOP

Right?

One missing part of this picture is how the side trace can reconnect with the root trace or otherwise handle the case where B needs to execute instead of C.

[lukego]

Just reflecting more. Here is an idea for how to step-by-step build the looping side trace above.

First we record the instructions that only execute in the side trace:

SIDE:
C

Then we replay the instructions that were already executed in the parent trace, just for reference in a location before the entry point into the side trace:

INHERIT:
A
SIDE:
C

Then we apply the standard loop optimization:

INHERIT:
A
SIDE:
C
LOOP:
A'
C'

Now we can prune the unused instructions before the SIDE entry point:

SIDE:
C
LOOP:
A'
C'

Then we have the looping side trace.

So this leaves me with two questions:

1. How do these looping traces connect with other traces? (Could be complicated / messy / prone to combinatorial explosion?)
2. How come the JIT currently sets up side traces by taking values from snapshots rather than by replaying the parent instructions? Is this for important reasons or only historical ones? See "super side trace" #108.