前面說了一些解析、生成ByteCode直至JIT的基本概念，下面是對照JavaScriptCore原始碼來大致瞭解它的實現。

從JS Script到Byte Code

首先說明Lexer, Parser和ByteCode的生成都是由ProgramExecutable初始化過程完成的。先在JSC的API evaluate()中會建立ProgramExecutable並指定指令碼程式碼。然後傳入Interpreter時，再透過CodeCache獲取的UnlinkedProgramCodeBlock就是已經生成ByteCode後的Code Block了。

下圖是CodeCache呼叫Parser和ByteCodeGenerator的序列圖:

而Lexer則是在Parser過程中呼叫的，如下圖:

再從類圖來觀察所涉及的幾個類之間的關係:

關於CodeBlock、UnlinkedCodeBlock和ScriptExecutable

CodeBlock可以理解為程式碼管理的類，按型別分為GlobalCodeBlock, ProgramCodeBlock, FunctionCodeBlock及EvalCodeBlock, 與之對應的UnlinkedCodeBlock和ScriptExecutable也有相似的繼承體系，如下所示:

UnlinkedCodeBlock儲存的是編譯後的ByteCode，而CodeBlock則會用於LLint和JIT。

ProgramExecutable則可以理解為當前所執行指令碼的大總管，從其名字上可以看出來是代表一個可執行程式。

它們的作用也很容易理解。

關於LLint的slow path

前面說過了LLint是基於offlineasm的組合語言，這裡只是介紹一下它的slow path. 為了處理一些操作，需要在LLint執行指令時呼叫一些C函式進行擴充套件處理，比如後面要說明的JIT統計功能，LLint提供一個呼叫C函式的介面，並將所有會被呼叫的C函式稱為slow path,如下圖所示:

程式碼可以在LowLevelInterpreterXXX.asm中看到。所以可以C函式宣告看到帶有SLOW_PATH的巨集。

關於JIT優化的觸發

首先JSC使用的是基於計數器的熱點探測方法。前面提到函式或迴圈體被執行若干次後會觸發JIT, 首先這個次數是可以通過JSC::Options中的thresholdForOptimizeSoon來設定的。然後在LLint在執行迴圈的ByteCode指令loop_hint和函式返回指令ret時會呼叫slow path中的C函式，進行次數統計和判斷，過程如下:

  其中會根據checkIfJITThresholdReached()返回結果來決定是否進行jitCompile.一旦要進行JIT編譯時，也是根據當前CodeBlock的型別，而執行鍼對不同函式或程式碼段的優化。下面顯示的是對一個頻繁使用的函式進行JIT編譯的操作:

其中計數的功能並非由CodeBlock直接實現，而是通過ExecutionCounter來管理的。主要關係如下:

系列索引: