On Thu, 2009-06-25 at 07:57 -0400, Stephen Pair wrote:
> 2009/6/24 Göran Krampe <goran at 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