This is awesome! I am not familiar with how compilers/VMs are generally implemented, but the tracelets and guards idea strikes me as very general - in particular, it looks like this approach could be applied to provide type inference to any dynamically typed language. Has this kind of thing been tried before?
In terms of optimization, is it possible to create tracelets that are not continuous regions in code? Roughly, if you identify two non contiguous tracelets, having the same inputs, and can guarantee the inputs havent changed in between, then you could merge them together. Because bigger tracelets would mean less guards and better performance.
As far as I know, you could try tracelets with any dynamic language.
And yes, you could try to share tracelets whose bodies are identical, but, unless their successor tracelets are also identical, you'd need to "dynamicise" the dispatch so you go down Path 1 when you're really tracelet 1 and Path 2 when you're really tracelet 2. We normally chain tracelets together by either falling through (if it's unconditional and the successor tracelet could be placed right next to it) or with jmp or branch instructions.
The tracing JIT was removed from Spidermonkey because it was brittle and didn't perform as well as the traditional JIT compiler(s) (Jaeger..., Ion...) that replaced it.
Comments
This is awesome! I am not familiar with how compilers/VMs are generally implemented, but the tracelets and guards idea strikes me as very general - in particular, it looks like this approach could be applied to provide type inference to any dynamically typed language. Has this kind of thing been tried before?
In terms of optimization, is it possible to create tracelets that are not continuous regions in code? Roughly, if you identify two non contiguous tracelets, having the same inputs, and can guarantee the inputs havent changed in between, then you could merge them together. Because bigger tracelets would mean less guards and better performance.
As far as I know, you could try tracelets with any dynamic language.
And yes, you could try to share tracelets whose bodies are identical, but, unless their successor tracelets are also identical, you'd need to "dynamicise" the dispatch so you go down Path 1 when you're really tracelet 1 and Path 2 when you're really tracelet 2. We normally chain tracelets together by either falling through (if it's unconditional and the successor tracelet could be placed right next to it) or with jmp or branch instructions.
EDIT: That's what I get for not reading the paper first.
The tracing JIT was removed from Spidermonkey because it was brittle and didn't perform as well as the traditional JIT compiler(s) (Jaeger..., Ion...) that replaced it.
note that, confusingly enough, "tracelets" have nothing to do with "tracing JITs".