On Thu, 2009-06-25 at 07:57 -0400, Stephen Pair wrote:
2009/6/24 Göran Krampe goran@krampe.se Hi!
Just dug up their paper on TraceMonkey for PLDI 2009: http://blog.mozilla.com/dmandelin/tracemonkey-paper-pldi-2009/ Seemingly a really nice detailed paper! regards, Göran
Reading through their papers, while I didn't spend a lot of time studying the matter, I got the sense that the optimization strategies that Self employed would effectively accomplish similar types of optimizations, but arrive at them in a simpler and more general manner.
One big advantage of a trace compiler is it doesn't compile whole methods so may be able to get by with a smaller code cache. While this probably doesn't matter so much on the desktop or server on some embedded devices it still will.
Implementing a trace compiler is likely to involve more frequent hooks than implementing a whole method compiler. With a whole method compiler only sends and returns need hooks, with a trace compiler at least every backward jump needs hooks for native code.
I've read some papers on a Java trace compiler that was slower than their whole method compiler but used much less memory.
It's an interesting way of getting type feedback with different trade offs to entire method compilers.
Bryce