不好意思

真是不好意思

耍孤僻是本人與生俱來的習慣

附帶的難以相處、難搞只是剛剛好而已

如此一來沒有什麼朋友也不過是理所當然而已

不好意思礙了眼

[research related]Trace-base Compilation Basic concept

TraceMonkey:

trace based JIT compiler TraceMonkey是一個Javascript的JIT compiler，己經被使用在firefox 3.1中，她的 implement 還是非常有特色的：

Dynamic Compilation with Traces

傳統JIT compiler的設計和static compiler非常像，如果在interpret的過程中發現某個function invoke的次數很多，就把這個function compile成native code（其實這個是Sun JVM的行為，Microsoft CLR沒有interpret的過程，直接把function JIT成native code）。

trace based compiler採取了不同的方法，在interpret bytecode的過程中，如果發現了一條"token"的backwards branch，就代表在source code中發現了一個loop。

當我們發現這樣的loop被執行了很多次之後，就從loop的head開始記錄整條bytecode的sequence，直到回到loop的tail。這樣的一條bytecode sequence就叫做一個trace，他實際上是loop的一次iteration。每當我們發現了一條這樣trace，就把她compile成native code，如果下次interpret進入這個trace，就改用生成的native code來執行。

很多時候loop裡會有不止一條performance-critical的path，所以我們得到的是一個trace tree。這棵tree是在interpret的過程中lazily創建出來的，每發現一條trace，就compile成native code，把tree擴展一下。對於nested loop，可以很容易地使用"nested tree"來構造。

function call對於trace tree是透明的，trace中的function call會被直接inline到trace tree中，從而沒有任何function call的cost。

這種trace compilation最大的好處是：對於任何一條trace，由於沒有任何的branch，control-flow、data-flow的分析會非常的簡單和快速，例如做SSA的時候會非常快，根本就不會有插入PHI的可能。（由於我們的trace是一條一條加入trace tree的）而且可以做到雖然每次只compile一條trace，但是對於整個loop是global optimized。

與傳統的method based compilation相比，trace更能代表程式的hot spot。其實source code中只有loop有必要被JIT，而method的細微性太大，很多不必要的code也被JIT了，浪費了很多時間。trace compilation就沒有這個問題，每個trace肯定是程式執行的hot spot。

Type Specialization

Javascript是dynamic type的，所以每條trace都要根據當時執行的variable的runtime type做specialization，產生effective的native code，下次進入這個trace的時候，如果類型匹配，就使用產生好的native code，否則就記錄一個新的trace。

reference from
http://ivanwangcn.spaces.live.com/blog/cns!F291BBD27380D1CA!474.entry