如何評價WebKit B3 JIT Compiler？

01-14

Introducing the B3 JIT Compiler
As of r195562, WebKit』s FTL JIT (Faster Than Light Just In Time compiler) now uses a new backend on OS X. The Bare Bones Backend, or B3 for short, replaces LLVMas the low-level optimizer in the FTL JIT.

想寫的都已經發在這裡了：[新聞][JavaScript引擎] WebKit JavaScriptCore用新的B3編譯器後端替代FTL JIT中的LLVM - 編程語言與高級語言虛擬機雜談（仮） - 知乎專欄

我們也用LLVM做JIT編譯器，所以對B3的消息還挺關注的。但感覺B3相對LLVM的部分好處，其實靠增強/改進LLVM自身也可以達到；這次分家感覺還是Filip跟LLVM組在撕…

贊同使用 ID 代替指針，至少 DU chain 可以這樣，在64bit系統上真是省不少內存呢。尤其是在一些比較極端的例子中，一個 Def 有幾萬的 Use. LLVM 本身的缺陷已經有很多的分析文章了，我覺得有一點可以提出來討論，LLVM後端的代碼生成框架是否有必要用Tabgen, 基本上代碼生成部分每個處理器都會定製代碼生成，能公用的部分越來越少，可以用一些基類來代替Tabgen.

Target 描述語言也是越來越複雜，同樣質疑是否有必要存在，用 target hook 的機制是否更好。

原文的大體思想R大已經總結得差不多了。我根據我淺薄的LLVM經驗來加點料：

LLVM設計實現的時候滿腦子是「compiled language」（該詞為Chandler原話），所以compile time只要&不比GCC差&不出現quadratic behavior及以上行為就開開心心了。而B3顯然是想榨乾榨乾榨乾。

當然LLVM在memory management方面還是下了功夫的，比如DenseMap和明確的ownership啦和全程手動的allocation。別笑，我才不會告訴你GCC雖然是C寫的，但是用了些immutable data structure，還偷偷寫了個garbage collector時不時給你收一下。C++由於include的原因生成出來的代碼數量本來就是O(n^2)的（你懂的），數據大卡GC簡直好看煞人。

啊。。扯遠了。內存分配方面B3肯定更好不會更差，簡言之就是用更多數組而少用鏈表。mutation？沒事我們用immutable data structure（誒是不是看著有點眼熟= =），哦不，是InsertionSet！InsertionSet不能算immutable！C++的數據結構，怎麼能算immutable呢？我只是暫時不mutate而已！當然B3也說「其實我們也不咋改的嘛」，所以mutation亂搞搞也不要緊；但放到LLVM就說不準了。

LLVM做JIT應該是給人偶爾生成代碼用的，實現dynamic language我覺得真不合適。幾十上百個pass每個pass都要把整個代碼輪一遍（雖然大多都是early return），雖然整體速度還是O(n)，但是其係數和少量pass每個pass做很多事（我不清楚B3是怎麼組織的）相比就大了幾十上百倍了。記住我們是工程師，事情到O(n)還沒完，要優化那個看都看不到的係數=w=。這塊要改的話感覺很難，因為每個pass都是獨佔所有代碼的，想要把多個pass機械地合併到一個visitation里應該有難度。

另一個問題就是specialization。這塊LLVM是沒辦法的，因為by design就是個generic IR，rust也能接，swift也能接，要保持面部整潔，大家就不能跑來胡亂塞塞塞（不過你看那intrinsic也是嚇一跳）。

後端的話亂七八糟的人都跑來分一杯羹，還會側漏出奇怪的東西到generic code裡面，比如有個primitive type叫ppc fp128你信嗎！說到Power，那個做Power的不知道什麼公司（霧）的技術支持（大霧）還不是特別給力/w。x86是沒什麼大問題的。但是別的架構人們也是不辭辛苦地貢獻了不少bug。所以想「按個按鈕就換在Power上跑」的話還是省省吧。當然B3的話肯定是x86和ARM啦。LLVM的ARM我不是很清楚，不知道是不是最後一根稻草什麼的（

優化的話我有點驚訝全篇隻字未提inline。這是被frontend撿去做了呢，還是dynamic language里壓根沒這習慣，比如dynamic language是得先做devirtualization才好inline？反正LLVM的devirtualization還沒起來。