[pypy-dev] Interpreter level array implementation
Carl Friedrich Bolz
cfbolz at gmx.de
Sat Jul 3 10:03:27 CEST 2010
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
> 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.
More information about the Pypy-dev