作者簡介

常開顏

中國科學院計算技術研究所直博生，研究方向為硬件編程語言、編譯技術。

---

如果讀者想了解更多有關?Runtime?相關的技術內容，歡迎加入編程語言社區 SIG-Runtime。

加入方式：文末有小助手微信，添加并備注加入 SIG-Runtime。

---

# 編譯器是什么 #

編程語言處理器可以分為三類，它們之間的關系用一句著名的話說就是：編譯器是特化的解釋器（a compiler is a specialized interpreter）[1]。

• 編譯器 Compiler?能夠給定一種語言的程序，輸出另一種語言里的等價程序（編譯過程會生成新的程序）

• 解釋器 Interpreter?能夠給定一個程序和程序的輸入，計算程序的結果（解釋過程不生成新的程序）

• 特化器 Specializer?能夠給定一個程序一些提前知道的輸入，創建一個僅需要剩下輸入的等價（但更高效）的程序

注：：即計算機實際執行的語言

作為一篇科普性質的綜述類文章，本文不打算挖掘深度，而是注重廣度，聚焦于提供一個 Runtime 的領域藍圖。就像 J.R.R.Tolkien 所說："你必須有一張地圖，不管多么粗糙。否則你會四處游蕩。(You must have a map, no matter how rough. Otherwise you wander all over the place.)"

# Runtime 是什么 #

Runtime?包括了?動態程序的相關理論?和?程序運行時的支持系統：

• 動態程序的相關理論?指程序動態特性相關的編程語言理論，比如動態程序驗證，運行時并發程序的動態驗證等；

• 運行時支持系統 runtime system?指保障程序在運行時正確執行的支持系統，比如垃圾回收系統、即時編譯系統、處理器系統等。

由于編程語言的運行不僅需要軟件系統的支撐，也需要硬件系統的支撐，因此 Runtime 涉及了軟件和硬件層次的許多交叉方面。此外，Runtime 不僅與通用編程語言有關，也與領域特定語言有關。在近來興起的深度學習編譯器中，許多框架都用到了即時編譯系統，比如 PyTorch。在云計算興起的時代，在可編程網絡領域也廣泛用到了編程語言作為接口對設備進行配置，比如阿里云太玄 OS 的跨平臺編程語言和編譯器 Lyra?[2]。

考慮到 Runtime 是一個涉及編程語言理論、體系結構、程序分析等的綜合領域，本文按照應用領域把相關的研究大致分為以下六個領域（如下圖所示），下面對每一個領域做說明。

Runtime 應用領域概覽

編譯器運行時

編譯器運行時屬于傳統的程序運行時支持系統，包括了通用語言虛擬機及其 JIT 編譯，比如：JVM、V8 等。

在傳統的編譯器運行時中，一個很大的部分是?垃圾回收技術（Garbage Collection），由此衍生出了?三色標記法、標記清掃法、引用計數法?等不同的垃圾回收方法。

其他和編程語言特性相關的特性還包括了反射、虛函數等。

涉及到的其他程序運行時的行為還有?并發?和?事務。

同時編譯器運行時也涵蓋了領域特定語言（Domain Specific Language）及其 JIT 編譯。領域特定語言是專用于某一個領域的編程語言，分為嵌入式領域特定語言和外部領域特定語言，嵌入式領域特定語言包括 Halide、TVM、Tensorflow、JAX 等，外部領域特定語言包括：云原生編程語言 Ballerina，硬件描述語言 Verilog、VHDL。

動態程序驗證

動態程序驗證與靜態驗證基于不同的系統。靜態程序的驗證一般是從作用域、類型等抽象特性上驗證程序的語義是否符合規范，而動態驗證則更為靈活。

從理論上講，可以歸結為?動態語義的驗證，比如采用?霍爾邏輯（Hoare Logic）?驗證數據結構的正確性，驗證循環的正確性；還可以使用?混合符號執行（Concolic Testing）?來測試程序，縮減符號執行造成的搜索空間爆炸的問題，比如使用混合符號執行 fuzzing。

從實踐上講，在 JVM 中，類的加載階段需要進行驗證，比如采用變量類型執行的方式，把變量的類型壓入虛擬機棧，在類型執行時判斷棧頂類型是否匹配。

動態程序分析

動態程序分析是對程序的動態行為進行分析，從而定位程序故障、進行調試或是進行更為激進的優化。在調試模式中，LLVM 采用?程序插樁?的方法，在局部變量的前后插樁方便調試時查看它們的值。LLVM 也采用了其他方法來加快程序的運行速度，比如收集性能制導優化的 profile，在每個分支指令后標注類似?!prof !0?的標識插入分支相對可能執行次數的元信息來輔助提高程序執行速度。還可以在程序運行時分析存儲的讀寫序列發現訪存沖突問題。

動態程序合成

動態程序的合成可以分為兩類，一種是?交互式程序合成，比如微軟在 Excel 中的自動填充技術，可以根據已經存在的單元格數據提取相關信息，與用戶輸入的數據進行對比，填充空白的單元格。第二種是收集運行時信息的?程序合成?技術，比如 TVM 的自動調度方案，采用運行時的性能模型合成高效率的代碼調度?[3]。

體系結構優化

編程語言與體系結構的交互伴隨運行過程始終，在動態編譯、并行編程和存儲系統方面都有體現。動態二進制指令翻譯是一種與此相關的研究，把一種形式的二進制指令翻譯為另一種形式的二進制指令，比如使用動態二進制翻譯的 CPU 模擬器 Qemu。還有用于并行編程的推測調度和多線程技術，比如軟件流水技術、超標量技術。近來興起的?非易失性存儲器（Non-Volatile Memory）?成為數據存儲領域新的研究載體，有研究在 Java 語言中加入與 NVM 相關的關鍵字，從編程語言的設計上方便操作新型存儲器。

集成電路設計

硬件是編程語言運行時的核心部分，向上提供指令集作為接口。領域特定語言（DSL）需要領域特定硬件（DSA）來作為實際載體加速。DSL 加速軟件開發，DSA 加速領域特定語言的運行速度是深度學習出現以來的新的趨勢。電子設計自動化工具作為硬件設計的重要組成部分一直是重要的組成部分。無論是傳統上的集成電路設計用的 Verilog、VHDL，還是后來為了方便編程演變出的 HLS 和 Pynq?[4]，都是為了加速芯片設計而產生的。但是近來興起的 Circt 和 XLS 沿襲了 LLVM 的思路，采用了復雜系統模塊化的思路，希望能夠對傳統集成電路設計工具解耦。

# Runtime 的過去?#

筆者在 Charles N. Fischer 所著的?Crafting a Compiler?[5]?中了解到 Runtime 的發展歷史。

編程語言設計的演變導致越來越復雜的運行時存儲組織方法的產生。舉例來說，數組可以被分配一個單一的固定大小的內存塊，而現在有一些新的編程語言，允許數組的大小在程序執行時指定，甚至能夠根據程序的需要動態擴展。

最初，所有的數據都是全局的，其生命周期跨越了整個程序。相應地，所有的存儲分配也是靜態的。在翻譯過程中，一個數據對象或指令序列在程序的整個執行過程中被簡單地放在一個固定的內存地址上。

在 1960 年代，Lisp 和 Algol 60 語言引入了局部變量，這些局部變量（local variables）僅僅能夠在子程序（subprogram）的執行的時候被訪問。這種特性導致了?棧式分配（stack allocation）?的產生。當過程或者方法被調用時，新的?棧幀（frame）?被壓入運行時棧。棧幀由為所有特定過程中的局部變量分配的空間組成。隨著過程的返回，它的棧幀被彈出，同時被局部變量占據的空間被取回。因此，僅僅是正在執行的過程被分配了空間，而不活躍的過程不需要數據空間。這使得相比早期使用靜態分配翻譯的空間效率更高。而且，遞歸的過程會由于同一個過程不相關嵌套的活動而請求多個棧幀。

Lisp 和隨后的像 C、C++、C# 和 Java 一類的語言，使得動態分配數據能夠在運行期間的任何時候被創建或者釋放。動態的數據請求堆分配（heap allocation），這使得內存塊在程序執行的任何時間以任何順序被分配和釋放。使用動態分配，數據對象的數目和大小不需要提前固定。每個程序的執行能夠定制它所需要的存儲分配。

所有的存儲分配技術利用數據區域（data area）這個符號。一個數據區域是一塊被編譯器知道的存儲，這個區域具有統一的存儲分配的必要條件。也就是說，所有在這個數據區域上的對象共享相同的數據分配策略。一個程序的全局變量能夠組成一個數據區域。當程序開始運行時，所有變量的空間被分配，并且變量仍然再分配直到執行結束。

這里給一個關于內存布局的問題，C++ 語言里給定一個?char *?的變量指針，如何判斷這個變量是?new?動態分配的還是在棧中呢？如下面的代碼所示，我們只需要根據棧是在程序虛擬空間的頂端自頂向下生長，而堆是在棧的下方自底向下生長這一規律就可以判斷。ch?變量是局部變量，分配在棧中，故其地址一定大于堆中的變量地址。

C 語言運行時空間分配

bool if_malloc(char *p) {char ch{};char *ch_p{&ch};if (ch_p> p) {return true;}else {return false;} }

C 語言沒有垃圾回收等運行時機制，而 C++ 語言有虛方法調用的運行時機制，比如下面的例子中，如果傳給?fun()?的參數是?Rectangle?的指針，那么最終調用的是?Rectangle?類中的?print()?方法，而不是?Shape?類中的方法。?

class Shape { public:virtual void print() {...} }class Rectangle:public Shape { public:virtual void print() override{...} }void fun(Shape* rec) {rec->print(); }

再以 Python 為例舉一個和垃圾回收有關的例子。Python 采用了?引用計數?作為主要的垃圾回收算法，同時結合了?分代收集（Generational Collection）算法。這是因為引用計數在循環引用的情況下，無法分辨出是否應該銷毀對象，從而導致內存泄漏。這時就需要顯式地調用 GC 模塊，如下所示。

import gcclass Base():def __init__(self):passc = Base() d = Base()# 出現循環引用 c.p = d d.p = c# 顯式執行回收 gc.collect()

# 談談 JIT 編譯 #

John Aycock 發表過一篇?A Brief History of Just-In-Time?[6]?的文章，對 JIT 的歷史做了比較詳盡的講解，本文對此文進行了解讀。

編譯器的設計涉及到很多領域，比如正則表達式、有限自動機等。傳統上，翻譯一個程序大體上可以分成兩種方法：編譯?和?解釋。編譯執行指的是把一個程序翻譯成匯編語言，最終翻譯為更適合執行的機器代碼。解釋執行消除了中間的步驟，可以立即執行。對比來講，編譯執行的效率更高，而解釋執行的靈活度更高。

那么?JIT 編譯?指的是什么呢？JIT 編譯（即 Just-In-Time Compile）是指程序開始執行后的動態編譯，用以同時獲得靜態編譯執行和動態解釋執行的收益。

我們從幾個方面比較 JIT、編譯執行和解釋執行。

執行時間上?對于直接被編譯為目標機器可執行的指令流而言，編譯的程序運行更快。靜態編譯的最大優勢就是能夠耗費任意時間來做程序分析與優化。而 JIT 系統不能引起程序執行的暫停，因此對于 JIT 來說，編譯時間也成為了約束 JIT 最主要的因素。
程序體積上?當語言的表示離機器代碼越高時，就意味著能夠攜帶更多的語義信息解釋執行平均來說更小。這也是為什么解釋執行的程序平均來說更小。
可移植性上?解釋執行的程序還有更便攜的特性。對于像高層次的源碼或者虛擬機器碼這種機器獨立的表示而言，只有解釋器需要提供在不同機器上的實現，而被解釋的程序不用考慮這些。
信息獲取上?解釋器能夠訪問輸入參數，控制流和目標機器特性這一類運行時的信息。每次運行時程序的信息都會發生變化；這些信息只有在運行時才能夠訪問。此外，解釋器也可以收集一些在靜態分析時不好判定的程序的類型信息。

如果一個程序的表示能夠被 JIT 系統以包括編譯為機器碼或者解釋的任何方式執行，就可以說這個程序是可執行的。需要注意的是，JIT 系統不僅包括了翻譯的功能，也包括了加載的功能，這一點和傳統的編譯器有很大不同。JIT 編譯器運行的時刻也很重要，當基于熱點計數探測時，如果設定在方法的開始點進入 JIT 后的代碼，則在方法出現某段時間特別長的循環時，JIT 編譯器始終無法執行，就會是一個問題。

JIT 編譯是一種提高解釋程序性能的方法，也被稱為動態編譯。相比靜態編譯，動態編譯有很多優勢?[7]。當運行 Java 或者 C# 應用程序時，運行時環境在程序運行時能夠生成利于編譯器優化性能的配置文件，即 PGO（Profile Guided Optimization）。這就可以產生更多的優化代碼。關于 JIT 編譯的一些缺點包括啟動時的延遲和運行時的編譯開銷。因此很多編譯器僅僅編譯那些頻繁使用的代碼。

#?JIT 編譯的歷史

我們討論的內容不包括?自修改代碼（self-modifying code）（即程序在運行期間（Runtime）會修改自身指令的代碼），因為基本上沒有編譯或者解釋的優化會把這個考慮進去。也就是說被編譯的程序自己并不知道編譯后自己的樣子。

可能進行 JIT 編譯的點?[8]

## LISP

最早的 JIT 實現可以追溯到 John McCarthy 于 1960 年編寫的 LISP。他在 《符號表達式的遞歸函數及其機器計算》?[9]?一書中提出了?把函數編譯為機器語言?的方法，從而無需將編譯器的工作輸出到打孔卡上。另外一個關于 JIT 早期的工作可以追溯到 1966 年，密西根大學為 IBM 7090 設計的?執行系統（Executive System）明確指出?匯編器（assembler）[10]?和?加載器（loader）[11]?能夠在程序執行時被用來翻譯和加載。Thompson 在 1968 年發表在 ACM 通訊的論文?[12]?開創了正則表達式，可以在 QED 文本編輯器中搜索子字符串。為了加速算法，Thompson 將正則表達式編譯到 IBM 7094 機器碼。

The time-space tradeoff.

在運行時間和空間的權衡總是 JIT 要考慮的最主要因素，如上圖所示。此外，一項 1971 年基于經驗的研究數據表明，大多數程序會花費大量的時間執行很少的一段代碼。基于這兩種情況，出現了兩種解決方法：混合代碼（Mixed Code）?和?拋棄型編譯（Throw-Away Compiling）。

## APL: Drag-along and Beating

APL?[13]（全稱是 A Programming Language 或 Array Processing Langauge），是由 Kenneth E. Iverson 在 1962 年設計的一門面向數組計算的編程語言。Kenneth 后來因對數學表達式和編程語言理論的貢獻而獲得了 1979 年的圖靈獎。

由于 APL 語言的動態特性，大多數 APL 的實現都是解釋性的。Abrams 在 1970 年提出?[14]?了?拖動（Drag-along）?和?跳動（Beating）?兩種 APL 實現的優化策略，這兩個策略都提高了數組作為操作數的速度，其中?拖動?是從時間上優化，跳動?是從空間上優化。

拖動 Drag-along

拖動 Drag-along?的策略是，通過收集上下文的信息，寄希望于未來會有一個更為高效的求值方法，因此?盡可能地推遲表達式求值（expression evaluation）。這種方法又被稱為?惰性求值（lazy evaluation）。

為了更直觀地表示惰性求值，下面給出一段偽代碼。直觀來講，我們只有到?print()?語句執行時才能夠看到程序的狀況。如果是解釋執行就需要?c?d?e?三個臨時存儲才能夠計算。懶惰求值是指并不立即計算?c?d?e，而是直到?print()?執行時才開始進行上面的計算，這樣做的好處就是既優化了信息又不影響用戶的觀察。當執行到?print(e)?時，惰性求值編譯器會發現?e=a+b+a+b+a=3*a+2*b=3*a+(b<<1)，這就極大地削弱了運算的強度和訪存的數量。

let c = a + b let d = c + a + b let e = d + a print(e)

跳動 Beating

跳動 Beating?通過代碼變換降低表達式求值時涉及到的數據操縱（data manipulation）的次數。具體來講，即通過將標準形式的代碼變換應用于數組的存儲訪問函數上，將原本直接訪問的變量替換為那些可以在無需操作數組值的情況下求值的表達式。

這么說有點抽象，接下來我用更詳細地例子解釋 beating。假設，在 C 語言里訪問數組都是用?A[i]?這種方式，并且我們已經知道了數組的數據布局。但如果想要從二維數組?A?得到它的轉置數組?B，就需要做一次拷貝。Beating 的思想是，不直接使用存儲（storage）來描述，而是增加一個中間層?數據描述子（data-descriptor），用來表示數據訪問的順序和范圍等。在加入數據描述子后，對數組的轉置等操作就不需要數據移動（Data movement）了。如果需要新的變換，只需要在數據描述子上變換，而不需要在存儲上變換，從而新的描述子和原來的描述子共享原始的數據 owner。

為了更清楚地說明中間層數據描述子，給出下面針對整數數組描述子的偽代碼描述。假設我們需要反轉線性表，我們無需逐個讀取線性表中的數據，這會耗費 O(N) 的時間復雜度，而只需要在數據描述子上重新賦值?begin?和?end，這樣時間復雜度僅需 O(1)。

/* 轉置數據描述 */ struct reverse_manipulator {int* data_array;int length;iterator begin; // 初始化為 data_array + length - 1iterator end; // 初始化為 data_array }/* 正向數據描述 */ struct data_manipulator {int* data_array;int length;iterator begin; // 初始化為 data_arrayiterator end; // 初始化為 data_array + length - 1 }

APL 實現

Abrams 設計的 APL Machine 由兩個共享相同內存和寄存器的獨立 JIT 編譯器組成。D-machine 應用跳動和拖動來推遲程序的求值，然后由 E-machine 進行求值。主要的機器寄存器是棧區（stacks），程序會被組織為邏輯段。Abrams 的工作使得為高級語言提供硬件支持變得流行。對 APL 語言有興趣的可以訪問 TryAPL：https://tryapl.org/

由于 Abrams 設計的?APL Machine?動態性很強，其類型和數據對象的屬性直到運行時才能得知，因此這兩種方法與 JIT 編譯相關。懶惰求值技術在一些編譯器里得到了應用，比如清華的即時編譯深度學習框架 Jittor、函數式語言 Haskell 等。然而跳動（beating）技術現在還沒有得到大規模的應用，當前業界與這種思想比較相似的就是為了降低顯存而設計的?重計算方法。

后來，Ronald L. Johnston 基于 Abrams 的 Drag-along 和 Beating 為 APL 實現了一個動態增量編譯器 APL\3000?[15]，是 JIT 編譯的一個早期例子。APL 實現的設計思想對今天的編譯器設計，尤其是數據密集型的編譯器設計仍然有很大的啟發性意義。

## Mixed Code, Throw-Away Code, and BASIC

混合代碼 Mixed Code?即把程序實現為?本地代碼（Native code）和?解釋代碼（Interpreted code）的混合形式。這種方法在 1973 年被 Dakin 和 Poole?[16]?以及 Dawson?[17]?分別提出。程序中被頻繁執行的代碼會被實現為本地代碼，而不頻繁執行的部分會被解釋執行，以此希望在產生很少內存占用的同時對速度幾乎不產生影響。這種實現方式考慮的都是細粒度的混合（舉個反例，程序是解釋執行，而使用的庫是本地代碼，這種就不算 Mixed Code）。

為了更直觀地表示混合代碼執行，下面寫一段偽代碼。

if (current_method.can_jit == true) {native_code = load_native_code(current_method);native_code(param); } else {virtual_pc = current_method.getEntry();run(virtual_pc); }

偽代碼的第一段?if?語句表明如果虛擬機判斷這個方法可以 JIT 執行，它會動態加載已經編譯好的代碼，然后執行這一段本地代碼。否則就進行解釋執行，獲得要執行方法的首指令位置，然后解釋執行。

混合代碼方法自 Pittman 1987 年提出了?自定義解釋器（Customizing the interpreter）?[18]?后迎來了重要轉折。與原本在程序中混合本地代碼不同的是，自定義解釋器將本地代碼表示為一種特殊的虛擬機器指令，然后程序整體被編譯成這種虛擬機器指令。

混合代碼的基本思想（即在不同類型的可執行代碼間切換）仍然在后來的 JIT 系統中被廣泛使用。但在當時的年代，同時將編譯器和解釋器保留在內存中成本太高。除此之外，即使假設大多數代碼會在解釋器和編譯器之間共享，仍然會需要維護兩部分行為上等價但完全不相關的代碼（即解釋器與編譯器的代碼生成器）。

一部分人認為?部分求值（Partial Evaluation）?或?程序特化（Program Specialization）?從某種程度上講是似是而非的，因為一個編譯器可以被看作是一個特殊的解釋器?[19]。然而部分求值技術現在沒有廣泛傳播。部分求值 / 程序特化?[20]，即在編譯時預先對一部分代碼進行計算，在運行時對代碼做特化（specialize），從而生成運行速度比原始程序更快的新程序。

下面以一段偽代碼為例解釋（運行時）程序特化。原始代碼在運行時會發現?d?是不變量，因此會被特化為下面的代碼。鑒于在運行時我們可以獲得更多的信息，因此可以對程序進行更多的優化。運行時的特化與模板中編譯時特化在形式上相似，針對的階段不同。

/* 原始的函數 */ void func(int a, int b, int c, int d) {... } /* 運行時，如果發現不變量，經過特化的函數 */ void func(int a, int b, int c, 5) {... }

因此，拋棄型編譯?[21]?作為一個純粹的空間優化技術被提出。與靜態編譯不同，拋棄型編譯只在有需要的時候對部分程序動態編譯。當內存耗盡時，一些或者所有已被編譯好的代碼可能被扔掉，如果有必要，這些代碼將在之后重新生成。

下面使用偽代碼解釋拋棄型編譯的異步過程。當方法被調用時，檢查是否已經 JIT 編譯好了，如果沒有編譯好，就先進行 JIT 編譯，然后執行本地代碼。如果內存用盡，就先刪除本地代碼。

method.on_call((param)=>{if(method.has_jit == false) {method.native_code = jit_compile(method);}method.native_code(param); })method.on_memory_runout(()=>{method.native_code.delete();method.has_jit = false; }))

BASIC 語言可以說是拋棄型編譯的試驗場。Brown?[21]?將拋棄型編譯看作是解決時間和空間權衡的好方法。Hammond?[22]?更為堅定，他認為除非內存緊張，使用拋棄型編譯會更有收益。

## HotSpot and FORTRAN

有關程序在運行時自動優化?熱點（hot spots）?的動態編譯最早是由 Gilbert Joseph Hansen 于 1974 年提出?[23]，他解決了三個重要的問題：

哪些代碼應該被優化？

Hansen 選擇了一個簡單并且低開銷的模型，為每個（通用意義上的）代碼塊維護一個執行頻率計數器（frequency-of-execution counter）。

這些代碼在什么時候優化？

Hansen 設定了一個執行次數的閾值。當計數器達到閾值后，就會把關聯的代碼塊作為下一層優化的候選隊列中。Supervisor 代碼會在兩個代碼塊間被調用，評估計數器是否達到閾值，如果達到了就做優化，然后將控制權轉移到下一個代碼塊中。

代碼應該被怎樣優化？

Hansen 采用了分次優化的方法，即將一系列機器相關和機器無關的優化分到不同的集合中，比如，一個代碼塊可能會先進行常量折疊（constant folding）的優化，在第二次優化時執行公共子表達式消除（common subexpression elimination）優化，第三次優化再執行代碼移動（code motion）優化。

Apply in Fortran

Hansen 將這種編譯優化方式應用在 Fortran 的編譯器中，優化器會對執行頻次不同的程序進行迭代式的優化，若一段代碼執行的足夠頻繁，最終會被編譯為機器碼。Hansen 的研究結果表明，針對 “hot spots” 做解釋和迭代優化，其執行成本往往遠低于傳統的編譯器優化（即對整個程序做優化）。這種優化方式較好地限制 JIT 系統在任何給定優化點的時間開銷，同時允許我們在 JIT 編譯器中做增量優化。

## Smalltalk

Smalltalk 是一種動態類型、反射式、面向對象編程語言?[24]。當新的方法被動態地添加到一個類時，Smalltalk 源代碼會被編譯為虛擬機代碼?[25]。Smalltalk 的動態更新和反射功能在四十年前都已遠遠領先與如今的許多主流語言。然而，Smalltalk 語言的運行十分慢，而且運行開銷極大，這是影響 Smalltalk 發展的主要原因之一。

為了提高 Smalltalk 的運行性能，Deutsch 和 Schiffman 從軟件層面做出了關鍵的優化。他們發現，只要表示之間的轉換對于用戶是自動的且透明的，那么就可以為信息選擇最有效的表示。這個思想放到現代編譯器中，可以引申為 IR 的轉換在不影響用戶行為的情況下可以選擇更高效的實現。

他們的系統使用了?虛擬機代碼到本地代碼的 JIT 編譯，并將該優化技術比作?宏擴展（macro-expansion）。有特色的地方在于，當開始執行時，程序會被 lazily compile 為本地代碼，并由系統緩存起來以供之后使用。該編譯系統與操作系統中的內存管理相關聯，編譯出的本地代碼永遠不會被操作系統的頁面兌換機制換到外存中（paged out），只會被丟棄然后在必要時重新生成。

## Self

Self 是一種基于原型的面向對象的程序設計語言?[26][27]，在一段時間內 Self 是 Smalltalk 最快的實現，并且僅比 C 慢兩倍，完全面向對象。

與本文中提到的許多其他語言相比，Self 更像是一種研究工具。Self 在很多方面受到 Smalltalk 的影響，兩者都是純粹的面向對象的語言。不同的是，Self 摒棄了類而采用了對象的概念，并試圖以其他方式統一一些概念，比如每一個動作都是動態的和可改變的，即使是基本的操作（如局部變量訪問）也需要調用一個方法。

Self 語言的復雜設計，激發了大家對 JIT 編譯和優化的開創和改進。Self 的大部分開發工作是在 Sun Microsystem 上進行的，因此后來很多技術被直接用在了 Java 的 HotSpot VM 上。在設計 JIT 的過程中，有研究者發現觸發機制比選擇機制重要得多。這也和不同的編碼風格有關，比如面向對象編程風格傾向于短的方法。

在 Self 編程語言中，可以在方法正在執行的時候修改，這個修改依賴于修改方法的運行堆棧。Self 編譯器的 JIT 優化還引入了?類型反饋（type feedback）?[28][29]，即程序執行時的類型信息由運行時系統收集，當下一次運行時可以根據這個類型信息進行更為激進的優化。下面分別是已知類型信息和未知類型信息時解釋器的動作，已知類型信息時判斷的條件更少，運行得更快。

def func(A, B):return A + Bfunc(0, 1) # 未知類型信息的目標偽代碼 if A.typeid == int:if B.typeid == int:return A.getintdata() + B.getintdata() # 已知類型信息的目標偽代碼 return A + B

Self 后來被 Sun 拋棄了，但對 Java 語言的研究仍在繼續。

## Slim Binaries and Oberon

在上個世紀，將軟件部署到不同的機器上是個大問題，因為不同的機器具有不同的體系結構。Franz 使用?瘦二進制文件（slim binaries）?[30][31]?來解決這個問題。

瘦二進制文件?包含一個高級的、獨立于機器表示的程序模塊。當模塊被加載時，會迅速生成會根據運行時的環境動態調整的可執行的代碼。至于為什么叫 “瘦”，可以考慮一個高層次的 IR 通常會比低層次的 IR 在單位空間上蘊含的信息更多，因此占用空間更小。

Franz 認為，就目標代碼的性能而言，一次生成整個模塊的代碼通常會優于 Smalltalk 和 Self 用的一次生成整個方法代碼的策略。因此對于瘦二進制文件方法而言，快速的代碼生成很關鍵。如果之后需要，生成的代碼可以被記錄下來而不是重新生成。

Franz 為 Oberon（一種通用編程語言，由 Niklaus Emil Wirth 在 1987 年推出）[32]?實現了一個動態代碼生成系統 Juice（https://github.com/berkus/Juice）。Juice 系統實現了瘦二進制文件，允許動態模塊（Module）的加載。加載和產生瘦二進制的代碼要比加載傳統二進制文件慢一些。從瘦二進制文件發明開始，Kistler 開始研究如何連續地進行運行時優化，也就是不斷地優化正在執行中程序的某一部分。

## Templates, ML, and C

這一部分介紹模板的相關內容，ML（Meta Language）語言相對較早，如今大家也不是很熟悉，但是 C 系的語言大家都很熟悉。ML 和 C 都采用了分階段編譯的方法。單個程序的編譯分為兩個階段：靜態編譯階段和動態編譯階段。在運行時之前，靜態編譯器編譯 “模板（templates）”，這些模板的本質是運行時由動態編譯器拼接在一起的構建塊（building blocks），里面會有一些值在運行時填充。模板在執行之前需要運行時翻譯，也就是特化，動態編譯器在連接模板之后會做運行時優化。需要注意的是，這里的模板不是現在 C++ 里的模板。這一個部分現在用的少，只看上面的概念也有點難懂，所以下面舉個例子，源自文獻?[33], 這個例子里?x?是靜態的，而?y?是動態的，是只有運行時才知道的。

// 源程序 int f(int x,int y) {int l;l = 2 * x;if(l==2)l=l+y;elsel=y*x;return l; }

上面是 C 語言的源程序，因為提取模板的方法有很多，下面選擇一種方案提取模板。

/*--t1-begin---*/ int f_t(int y) {int l; /*--t1-end-----*/ /*--t2-begin-----*/l=[h1]+y; /*--t2-end-----*/ /*--t3-begin-----*/l=y*[h2]; /*--t3-end-----*/ /*--t4-begin-----*/return l; } /*--t4-end-----*/

上面的代碼總共被劃分成了 4 個模板。因為參數?x?是原始過程聲明為靜態的，所以他們可以確定，但是我們不知道程序的調用者現在給它什么值。因此它作為運行時特化器的一個參數出現，運行時的值被轉換成了洞，使用?[h1]?和?[h2]?來表示。

下面是動態編譯器如何特化函數?f?的過程，此時模板使用運行時的值實例化。

void rt_spec_f(int x) {int l;dump_template(t1);l=2*x;if(l==2) {dump_template(t2);instantiate_hole(t2,l);}else {dump_template(t3);instantiate_hole(t3,x);}dump_template(t4); }

局部變量?l?既在靜態運算中，也在動態運算中。運行時特化器的第一個運算是 dump 模板?t1。原始過程的第一個指令能夠被執行是因為它是純靜態的。然后條件語句被執行。條件測試結果決定 dump 模板?t2?還是 dump 模板?t3。dump 后的模板使用運行時的值實例化。最后模板?t4?被實例化。

## Erlang

Erlang 是一種通用的并發的、函數式、分布式的編程語言，用于設計大型軟實時（soft real-time）系統。Erlang 官方實現的虛擬機 BEAM，可以解釋執行；還有編譯為二進制的高性能編譯器 HiPE（High Performance Erlang，由 Uppsala University 開發?[34]）；也支持腳本的方式來執行。

Erlang 的 HiPE 實現旨在解決性能問題。通常情況下，HiPE 編譯器會比 BEAM 編譯器生成更快的代碼。作為一個沒有設計歷史包袱的系統，HiPE 的突出之處在于用戶必須顯式調用 JIT 編譯器，這樣做可以在混合代碼執行上提供的性能與代碼空間權衡之上提供給用戶更好的控制度。HiPE 在本地代碼和解釋代碼之間來回執行 “模式切換” 時非常小心，在明顯的調用和返回位置、以及拋出異常時可能需要模式切換。它們的調用使用調用者的模式。

## Specialization and O’Caml

O'Caml 是另外一種函數式編程語言，可以看做是 ML 的一種方言?[35]。O'Caml 的解釋器一直致力于?運行時特化（run-time specilization）的工作。

Piumarta 和 Riccardi 把解釋器的指令特化為正在運行的程序?[36]。他們首先把解釋的字節碼動態翻譯到直接線程代碼，然后把指令塊動態組合成為新的 “宏操作碼”，修改代碼以使用新指令。這減少了指令分派的開銷，并為宏操作碼中的優化提供了機會。如果指令是分開的，那么這種優化是不可能的。他們的技術沒有考慮動態執行路徑，但是指出了它最適合分派時間是影響性能相對較大因素的低級指令集。

## Prolog

Prolog?[37]?是一個面向邏輯、動態編譯的編程語言。Prolog 基于謂詞邏輯，具有很強的聲明性特征。最初被運用于自然語言等研究領域，現在被廣泛應用在人工智能的研究中，比如建造專家系統、自然語言理解等。

為了讓 Prolog 程序的解釋執行更加高效，Prolog 代碼會被編譯為 WAM（Warren Abstract Machine，沃倫抽象機）指令。SICStus 作為 Prolog 編譯器的最大供應商，提供了一系列基于 WAM 的 Prolog 實現。Haygood 與 SICStus 團隊一起，開發了一種新的 Prolog 實現，能夠被調用并且動態加載輸出?[38]，既具備一定的可移植性，又一定程度上提高了性能。（SICStus Prolog 官網：https://sicstus.sics.se，更多介紹可以閱讀：SICStus Prolog -- the first 25 years.[39]）

## Java and JIT

Java 是一門通用的面向對象的編程語言，于 1995 年由 Sun 正式發布后，伴隨著互聯網的迅猛發展而發展，逐漸成為重要的網絡編程語言。

不同于當時的其他編譯型語言或解釋型語言，Java 先將源碼靜態編譯為虛擬機字節碼指令，然后再依賴不同平臺的 Java 虛擬機（JVM）來解釋執行字節碼，從而具備跨平臺的特性。早期的 JVM 只是解釋器，解釋字節碼很慢，這一定程度上影響了 Java 的運行效率。因此，提高 Java 的運行效率又重新激發了研究者們對 JIT 的興趣。而加快 Java 程序運行速度的核心方法就是對 Java 字節碼的?Just in Time Compile（即 JIT 編譯）。

Cramer 等 Sun 研發人員觀察到?[40]，JIT 編譯帶來的速度提升是有上限的，在他們運行的一個配置文件中，適當的解釋僅占執行時間的 68%。他們主張直接使用 JVM 字節碼（堆棧機指令集，stack-based）作為 JIT 編譯和優化的中間表示。但是只有從字節碼到本地代碼的翻譯是不夠的，還需要代碼優化，而傳統的優化技術是昂貴的。因此，大家尋找對優化算法的改進，盡可能在算法的執行速度和編譯速度之間取得平衡。

Burke 等人提出了只編譯的策略?[41]，沒有任何解釋器。他們的系統也是用 Java 實現的，對 JIT 的改進直接使他們的系統受益。

Agesen?[42]?將 JVM 字節碼翻譯成 Self 代碼，以利用 Self 編譯器的優化。

Azevedo 等人?[43]?嘗試用注釋將代碼優化的工作轉移到運行時間之前，高效的 JIT 優化所需的信息被預先計算并作為注釋標記到字節碼上，然后由 JIT 系統使用以協助其工作。

Plezbert 和 Cytron?[44]?提出并評估了 Java 的 “連續編譯” （continuous compilation）的想法，其中解釋器和編譯器將同時執行，最好是在不同的處理器上執行。

# JIT 系統的分類

Aycock 將 JIT 分為四類：

觸發方式 Invocation

如果用戶必須明確地采取一些行為來調用運行時的編譯，那么 JIT 編譯器就是顯式調用的（explicitly invoked）。一個隱式調用的 JIT 編譯器對用戶來說是透明的。

執行方式 Executability

若 JIT 的源語言和目標語言是相同的，則 JIT 是單一執行（monoexecutable）的。否則，該系統就是多執行的（polyexecutable）。

即使 JIT 是單一執行的，JIT 系統仍然會做 on-the-fly 的優化。（on-the-fly 是指執行過程中伴隨的過程，并不打斷執行，或者說 on-the-fly 是一種無縫的切換。）?這種優化是單一執行的優勢，它并不翻譯代碼到新的語言，只是做運行時的 JIT 優化。

還有一種 JIT 系統是多執行（polyexecutable）的，這樣的 JIT 系統（注意不是編譯器）能夠執行多于一種的語言。多執行的 JIT 系統可以決定何時需要調用編譯器。例如，JVM 是一個典型的多執行的 JIT 系統，其中的 Java 字節碼在 JIT 執行時會被編譯為機器代碼，JVM 能夠執行 Java 字節碼（解釋執行）和機器代碼（JIT 后執行）這兩種語言。

并發方式 Concurrency

如果程序需要暫停從而運行 JIT 編譯器，這個 JIT 系統就不是并發的。如果 JIT 編譯器能夠在單獨的線程或者進程甚至處理器上，與程序并發地執行，則該 JIT 系統是個并發的 JIT 系統。

實時性 Real-time

即，如果 JIT 系統能夠提供實時的保證，也就是說 JIT 編譯器能夠保證在多長時間內完成任務，就說這個 JIT 系統是實時保證的。

# JIT 編譯的挑戰

隨著 JIT 編譯的發展，一些問題和挑戰也隨之出現：

二進制代碼生成

事實上，二進制代碼的動態生成充滿了挑戰。比如，有些程序中會包含一些在最開始代碼生成階段無法獲取的信息，比如前向分支的目標（可以參考《編譯原理》紫龍書對于 if 語句翻譯為 goto 回填的問題），我們需要知道后面的代碼塊后才能回填（Backpatch）到合適的位置上。

緩存

在緩存問題上，緩存一致性問題已經有協議來保證，那么最重要的是提高 JIT 代碼加載的速度。能夠在執行之前把 JIT 代碼從內存載入 Cache 加快執行速度，并且能夠合理劃分需要 JIT 部分的大小，不要使得 JIT 生成后的二進制代碼被頻繁地換入換出 Cache。

除此之外，JVM 等現代 JIT 系統在內存中開辟了代碼緩存，這個區域負責存儲編譯為本機代碼的字節碼，代碼緩存具有固定的大小。如果這個區域滿，JVM 會停止編譯。而對于每個編譯的方法，JVM 提供一個熱度計數器，如果計數器的值小于閾值，JVM 就釋放這段預編譯代碼?[45]。

執行

可執行的代碼存放的位置可能會被操作系統所限制。比如，生成的 JIT 代碼如果存放在數據區還要顯式地聲明數據區的可執行屬性，這時的代碼區和數據區的界限就變得不明晰。舉例來說，在安全領域經常使用的 shellcode 就是放在數據區的一段可執行代碼，用來發送到服務器利用特定漏洞的代碼，一般可以獲取權限。

# Runtime 的未來 #

由于程序靜態分析和優化的局限性，JIT 編譯兼具靜態編譯和動態優化的優勢就更加明顯。在深度學習等技術催生的各種領域特定語言涌現的當下，如果拓寬傳統 JIT 編譯的應用范圍，適配更多不同的語言也是一個重要的問題。GraalVM?[46]?是一個把傳統的編譯技術與云環境結合起來的項目，給云原生編譯器也開了一扇新的天窗。

---

參 考

[1] The magic mix: interpreter, compiler, specializer. https://www.cs.dartmouth.edu/~doug/cs118/mix.html

[2] Jiaqi Gao, Ennan Zhai, Hongqiang Harry Liu, Rui Miao, Yu Zhou, Bingchuan Tian, Chen Sun, Dennis Cai, Ming Zhang, and Minlan Yu. 2020. Lyra: A Cross-Platform Language and Compiler for Data Plane Programming on Heterogeneous ASICs. In Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and protocols for computer communication (SIGCOMM '20). Association for Computing Machinery, New York, NY, USA, 435–450. DOI: https://doi.org/10.1145/3387514.3405879

[3] Interactive Program Synthesis by Augmented Examples https://tianyi-zhang.github.io/files/uist2020-interactive-program-synthesis.pdf

[4] PYNQ - Python productivity for Zynq - Home http://www.pynq.io/

[5] Charles N. Fischer, Ronald K. Cytron, and Richard J. LeBlanc. 2009. Crafting A Compiler (1st. ed.). Addison-Wesley Publishing Company, USA.

[6] John Aycock. 2003. A brief history of just-in-time. ACM Comput. Surv. 35, 2 (June 2003), 97–113. DOI: https://doi.org/10.1145/857076.857077

[7] Just in Time Compilation Explained https://www.freecodecamp.org/news/just-in-time-compilation-explained/

[8] Hiroshi Inoue etc. Adaptive Multi-Level Compilation in a Trace-based Java JIT Compiler.

[9] MCCARTHY, J. 1960. Recursive functions of symbolic expressions and their computation by machine, part I. Commun. ACM 3, 4, 184–195. http://www-formal.stanford.edu/jmc/recursive.pdf

[10] UNIVERSITY OF MICHIGAN. 1966b. The “University of Michigan Assembly Program” (“UMAP”). In University of Michigan Executive System for the IBM 7090 Computer, Vol. 2. University of Michigan, Ann Arbor, MI.

[11] UNIVERSITY OF MICHIGAN. 1966a. The System Loader. In University of Michigan Executive System for the IBM 7090 Computer, Vol. 1. University of Michigan, Ann Arbor, MI.

[12] THOMPSON, K. 1968. Regular expression search algorithm. Commun. ACM 11, 6 (June), 419–422.

[13] APL - Wikipedia https://en.wikipedia.org/wiki/APL_(programming_language)

[14] ABRAMS, P. S. 1970. An APL machine. Ph.D. dissertation. Stanford University, Stanford, CA. Also, Stanford Linear Accelerator Center (SLAC) Rep. 114.

[15] THE DYNAMIC INCREMENTAL COMPILER OF APL\3000. http://www.softwarepreservation.org/projects/apl/Papers/DYNAMICINCREMENTAL

[16] DAKIN, R. J. AND POOLE, P. C. 1973. A mixed code approach. The Comput. J. 16, 3, 219–222.

[17] DAWSON, J. L. 1973. Combining interpretive code with machine code. The Comput. J. 16, 3, 216–219.

[18] PITTMAN, T. 1987. Two-level hybrid interpreter/native code execution for combined space-time program efficiency. In Proceedings of the SIGPLAN Symposium on Interpreters and Interpretive Techniques. ACM Press, New York, NY, 150–152.

[19] JONES, N. D., GOMARD, C. K., AND SESTOFT, P. 1993. Partial Evaluation and Automatic Program Generation. Prentice Hall, Englewood Cliffs, NJ.

[20] Partial Evaluation - Wikipedia https://en.wikipedia.org/wiki/Partial_evaluation

[21] BROWN, P. J. 1976. Throw-away compiling. Softw.—Pract. Exp. 6, 423–434. https://doi.org/10.1002/spe.4380060316

[22] HAMMOND, J. 1977. BASIC—an evaluation of processing methods and a study of some programs. Softw.—Pract. Exp. 7, 697–711.

[23] HANSEN, G. J. 1974. Adaptive systems for the dynamic run-time optimization of programs. Ph.D. dissertation. Carnegie-Mellon University, Pittsburgh, PA. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.376.3638&rep=rep1&type=pdf

[24] SmallTalk - Wikipedia https://en.wikipedia.org/wiki/Smalltalk

[25] GOLDBERG, A. AND ROBSON, D. 1985. Smalltalk-80:The Language and its Implementation. AddisonWesley, Reading, MA.

[26] UNGAR, D. AND SMITH, R. B. 1987. Self: The power of simplicity. In Proceedings of OOPSLA ’87. 227–242.

[27] SMITH, R. B. AND UNGAR, D. 1995. Programming as an experience: The inspiration for Self. In Proceedings of ECOOP ’95.

[28] HOLZLE, U. 1994. Adaptive optimization for Self: Reconciling high performance with exploratory programming. Ph.D. dissertation. CarnegieMellon University, Pittsburgh, PA.

[29] HOLZLE, U. AND UNGAR, D. 1994a. Optimizing dynamically-dispatched calls with run-time type feedback. In Proceedings of PLDI ’94. 326–336.

[30] FRANZ, M. 1994. Code-generation on-the-fly: A key to portable software. Ph.D. dissertation. ETH Zurich, Zurich, Switzerland.

[31] FRANZ, M. AND KISTLER, T. 1997. Slim binaries. Commun. ACM 40, 12 (Dec.), 87–94. https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108.1711&rep=rep1&type=pdf

[32] Oberon - Wikipedia https://en.wikipedia.org/wiki/Oberon_(programming_language)

[33] Carles Consel. A General Approach for Run-Time Specialization and its Application to C.

[34] Erlang - HiPE http://erlang.org/documentation/doc-10.3/lib/hipe-3.18.3/doc/html/HiPE_app.html

[35] REMY, D., LEROY, X., AND WEIS, P. 1999. Objective Caml—a general purpose high-level programming language. ERCIM News 36, 29–30.

[36] PIUMARTA, I. AND RICCARDI, F. 1998. Optimizing direct threaded code by selective inlining. In Proceedings of PLDI ’98. 291–300.

[37] Prolog - Wikipedia https://en.wikipedia.org/wiki/Prolog

[38] HAYGOOD, R. C. 1994. Native code compilation in SICStus Prolog. In Proceedings of the Eleventh International Conference on Logic Programming. 190–204. https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.6147&rep=rep1&type=pdf

[39] Mats Carlsson, Per Mildner: SICStus Prolog -- the first 25 years. CoRR abs/1011.5640 (2010) https://arxiv.org/abs/1011.5640

[40] CRAMER, T., FRIEDMAN, R., MILLER, T., SEBERGER, D., WILSON, R., AND WOLCZKO, M. 1997. Compiling Java just in time. IEEE Micro 17, 3 (May/June), 36–43.

[41] BURKE, M. G., CHOI, J.-D., FINK, S., GROVE, D., HIND, M., SARKAR, V., SERRANO, M. J., SREEDHAR, V. C., AND SRINIVASAN, H. 1999. The Jalapeno dynamic optimizing compiler for Java. In Proceedings of JAVA ’99. 129–141.

[42] AGESEN, O. 1997. Design and implementation of Pep, a Java just-in-time translator. Theor. Prac. Obj. Syst. 3, 2, 127–155.

[43] AZEVEDO, A., NICOLAU, A., AND HUMMEL, J. 1999. Java annotation-aware just-in-time (AJIT) compilation system. In Proceedings of JAVA ’99. 142–151.

[44] PLEZBERT, M. P. AND CYTRON, R. K. 1997. Does “just in time” = “better late then never”? In Proceedings of POPL ’97. 120–131.

[45] jvm-code-cache https://www.baeldung.com/jvm-code-cache

[46] GraalVM - Wikipedia https://en.wikipedia.org/wiki/GraalVM

原文轉載自?編程語言Lab-從 JIT 編譯看 Runtime 的過去與未來

總結

以上是生活随笔為你收集整理的从 JIT 编译看 Runtime 的过去与未来的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。