[pypy-dev] Interpreter level array implementation

Carl Friedrich Bolz cfbolz at gmx.de
Sat Jul 3 10:03:27 CEST 2010

Hi Paolo,

2010/7/3 Paolo Giarrusso <p.giarrusso at gmail.com>:
>> It requires thinking. It's harder to do because we don't know
>> statically upfront how many paths we'll compile to assembler, but I
>> can think about ways to mitigate that.
> Isn't there some existing research about that in the 'tracing'
> community? As far as I remember, the theory is that traces are
> assembled in trace trees, and that each time a (simplified*) SSA
> optimization pass is applied to the trace tree to compile it. Not sure
> whether they do it also for Javascript, since there compilation times
> have to be very fast, but I guess they did so in their Java compiler.

There are two ways to deal with attaching now traces to existing ones.
On the one hand there are trace trees, which recompile the whole tree
of traces when a new one is added. This can be costly. On the other
hand, there is trace stitching, which just patches the existing trace
to jump to the new one. PyPy (and TraceMonkey, I think) uses trace

The problem with loop-invarian code motion is that when you stitch in
a new trace (what we call a bridge) it is not clear that the code that
was invariant so far is invariant on the new path as well.


Carl Friedrich

More information about the Pypy-dev mailing list