Fast enough VMs in fast enough time
> RPython badges itself as a meta-tracing system, meaning that the user's end program isn't traced directly (which is what Figure 1 suggests), but rather the interpreter itself is traced.<p>Isn't that exactly what would happen if you wrote an interpreter in <i>any</i> language with a tracing VM (ie. LuaJIT)?  How is writing an interpreter in RPython better than writing one with LuaJIT?  RPython makes you insert these hints to the trace compiler (can_enter_jit, jit_merge_point) about when to start/stop running a trace, does this buy you anything?  If I had to guess, I'd suspect that this is actually a net loss because you have to guess ahead-of-time where it would make sense to start tracing.  This sort of guessing is notoriously hard to do.  An implementation like LuaJIT automatically decides when to start tracing based on run-time behavior, which seems like a more robust approach.<p>The one thing I <i>do</i> find very interesting about RPython is how it subsets a dynamic language such that types can be statically analyzed.  I always wondered whether this was possible and what kind of restrictions you'd have to enforce.  It's great to see an actual example of this -- it will be very instructive to anyone trying to do a similar thing.<p>But as far as using RPython as a "meta-tracing system," I'm not seeing what's ground-breaking here.  I'd bet 50 cents that writing an interpreter in LuaJIT will be faster than writing it in RPython.  And if I'm wrong about that, I'd bet 50 more cents that the reason RPython wins is because it's statically analyzable, <i>not</i> because of anything that's unique about its "meta-tracing system."  I'm not sure that term really means anything.