背景

　　HHVM 是 Facebook 開發的高性能 PHP 虛擬機，宣稱比官方的快9倍，我很好奇，于是抽空簡單了解了一下，并整理出這篇文章，希望能回答清楚兩方面的問題：

• HHVM 到底靠譜么？是否可以用到產品中？
• 它為什么比官方的 PHP 快很多？到底是如何優化的？

　　你會怎么做？

　　在討論 HHVM 實現原理前，我們先設身處地想想：假設你有個 PHP 寫的網站遇到了性能問題，經分析后發現很大一部分資源就耗在 PHP 上，這時你會怎么優化 PHP 性能？

　　比如可以有以下幾種方式：

• 方案1，遷移到性能更好的語言上，如 Java、C++、Go。
• 方案2，通過 RPC 將功能分離出來用其它語言實現，讓 PHP 做更少的事情，比如 Twitter 就將大量業務邏輯放到了 Scala 中，前端的 Rails 只負責展現。
• 方案3，寫 PHP 擴展，在性能瓶頸地方換 C/C++。
• 方案4，優化 PHP 的性能。

　　方案1幾乎不可行，十年前 Joel 就拿 Netscape 的例子警告過，你將放棄多年的經驗積累。尤其是像 Facebook 這種業務邏輯復雜的產品，PHP 代碼實在太多了，據稱有2千萬行（引用自 [PHP on the Metal with HHVM]），修改起來的成本恐怕比寫個虛擬機還大，而且對于一個上千人的團隊，從頭開始學習也是不可接受的。

　　方案2是最保險的方案，可以逐步遷移，事實上 Facebook 也在朝這方面努力了，而且還開發了 Thrift 這樣的 RPC 解決方案。Facebook 內部主要使用的另一個語言是 C++，從早期的 Thrift 代碼就能看出來，因為其它語言的實現都很簡陋，沒法在生產環境下使用。

　　目前在 Facebook 中據稱 PHP:C++ 已經從 9:1 增加到 7:3 了，加上有 Andrei Alexandrescu 的存在，C++ 在 Facebook 中越來越流行。但這只能解決部分問題，畢竟 C++ 開發成本比 PHP 高得多，不適合用在經常修改的地方，而且太多 RPC 的調用也會嚴重影響性能。

　　方案3看起來美好，實際執行起來卻很難，一般來說性能瓶頸并不會很顯著，大多是不斷累加的結果，加上 PHP 擴展開發成本高，這種方案一般只用在公共且變化不大的基礎庫上，所以這種方案解決不了多少問題。

　　可以看到，前面3個方案并不能很好地解決問題，所以 Facebook 其實沒有選擇的余地，只能去考慮 PHP 本身的優化了。

　　更快的 PHP

　　既然要優化 PHP，那如何去優化呢？在我看來可以有以下幾種方法：

• 方案1，PHP 語言層面的優化。
• 方案2，優化 PHP 的官方實現（也就是 Zend）。
• 方案3，將 PHP 編譯成其它語言的 bytecode（字節碼），借助其它語言的虛擬機（如 JVM）來運行。
• 方案4，將 PHP 轉成 C/C++，然后編譯成本地代碼。
• 方案5，開發更快的 PHP 虛擬機。

　　PHP 語言層面的優化是最簡單可行的，Facebook 當然想到了，而且還開發了 XHProf 這樣的性能分析工具，對于定位性能瓶頸是很有幫助的。

　　不過 XHProf 還是沒能很好解決 Facebook 的問題，所以我們繼續看，接下來是方案2。簡單來看，Zend 的執行過程可以分為兩部分：將 PHP 編譯為 opcode、執行 opcode，所以優化 Zend 可以從這兩方面來考慮。

　　優化 opcode 是一種常見的做法，可以避免重復解析 PHP，而且還能做一些靜態的編譯優化，比如 Zend Optimizer Plus，但由于 PHP 語言的動態性，這種優化方法是有局限性的，樂觀估計也只能提升20%的性能。另一種考慮是優化 opcode 架構本身，如基于寄存器的方式，但這種做法修改起來工作量太大，性能提升也不會特別明顯（可能30%？），所以投入產出比不高。

　　另一個方法是優化 opcode 的執行，首先簡單提一下 Zend 是如何執行的，Zend 的 interpreter（也叫解釋器）在讀到 opcode 后，會根據不同的 opcode 調用不同函數（其實有些是 switch，不過為了描述方便我簡化了），然后在這個函數中執行各種語言相關的操作（感興趣的話可看看深入理解 PHP 內核這本書），所以 Zend 中并沒有什么復雜封裝和間接調用，作為一個解釋器來說已經做得很好了。

　　想要提升 Zend 的執行性能，就需要對程序的底層執行有所解，比如函數調用其實是有開銷的，所以能通過 Inline threading 來優化掉。它的原理就像 C 語言中的 inline 關鍵字那樣，但它是在運行時將相關的函數展開，然后依次執行（只是打個比方，實際實現不太一樣），同時還避免了 CPU 流水線預測失敗導致的浪費。

　　另外還可以像 JavaScriptCore 和 LuaJIT 那樣使用匯編來實現 interpreter，具體細節建議看看 Mike 的解釋。

　　但這兩種做法修改代價太大，甚至比重寫一個還難，尤其是要保證向下兼容，后面提到 PHP 的特點時你就知道了。

　　開發一個高性能的虛擬機不是件簡單的事情，JVM 花了10多年才達到現在的性能，那是否能直接利用這些高性能的虛擬機來優化 PHP 的性能呢？這就是方案3的思路。

　　其實這種方案早就有人嘗試過了，比如 Quercus 和 IBM 的 P8，Quercus 幾乎沒見有人使用，而 P8 也已經死掉了。Facebook 也曾經調研過這種方式，甚至還出現過不靠譜的傳聞 ，但其實 Facebook 在 2011 年就放棄了。

　　因為方案3看起來美好，但實際效果卻不理想，按照很多大牛的說法（比如 Mike），VM 總是為某個語言優化的，其它語言在上面實現會遇到很多瓶頸，比如動態的方法調用。關于這點在 Dart 的文檔中有過介紹，而且據說 Quercus 的性能與 Zend+APC 比差不了太多（[來自The HipHop Compiler for PHP]），所以沒太大意義。

　　不過 OpenJDK 這幾年也在努力，最近的 Grall 項目看起來還不錯，也有語言在上面取得了顯著的效果，但我還沒空研究 Grall，所以這里無法判斷。

　　接下來是方案4，它正是 HPHPc（HHVM 的前身）的做法，原理是將 PHP 代碼轉成 C++，然后編譯為本地文件，可以認為是一種 AOT（ahead of time）的方式，關于其中代碼轉換的技術細節可以參考 The HipHop Compiler for PHP 這篇論文，以下是該論文中的一個截圖，可以通過它來大概了解：

　　這種做法的最大優點是實現簡單（相對于一個 VM 來說），而且能做很多編譯優化（因為是離線的，慢點也沒事），比如上面的例子就將“- 1”優化掉了。但它很難支持 PHP 中的很多動態的方法，如 eval()、create_function()，因為這就得再內嵌一個 interpreter，成本不小，所以 HPHPc 干脆就直接不支持這些語法。

　　除了 HPHPc，還有兩個類似的項目，一個是 Roadsend，另一個是 phc ，phc 的做法是將 PHP 轉成了 C 再編譯，以下是它將 file_get_contents($f) 轉成 C 代碼的例子：

static php_fcall_info fgc_info;
php_fcall_info_init ("file_get_contents", &fgc_info);
php_hash_find (LOCAL_ST, "f", 5863275, &fgc_info.params);
php_call_function (&fgc_info);

　　話說 phc 作者曾經在博客上哭訴，說他兩年前就去 Facebook 演示過 phc 了，還和那里的工程師交流過，結果人家一發布就火了，而自己忙活了4年卻默默無聞，現在前途渺茫。。。

　　Roadsend 也已經不維護了，對于 PHP 這樣的動態語言來說，這種做法有很多的局限性，由于無法動態 include，Facebook 將所有文件都編譯到了一起，上線時的文件部署居然達到了 1G，越來越不可接受了。

　　另外有還有一個叫 PHP QB 的項目，由于時間關系我沒有看，感覺可能是類似的東東。

　　所以就只剩下一條路了，那就是寫一個更快的 PHP 虛擬機，將一條黑路走到底。或許你和我一樣，一開始聽到 Facebook 要做一個虛擬機是覺得太離譜，但如果仔細分析就會發現其實也只有這樣了。

　　更快的虛擬機

　　HHVM 為什么更快？在各種新聞報道中都提到了 JIT 這個關鍵技術，但其實遠沒有那么簡單，JIT 不是什么神奇的魔法棒——用它輕輕一揮就能提升性能，而且 JIT 這個操作本身也是會耗時的，對于簡單的程序沒準還比 interpreter 慢，最極端的例子是 LuaJIT 2 的 Interpreter 就稍微比 V8 的 JIT 快。所以并不存在絕對的事情，更多還是在細節問題的處理上，HHVM 的發展歷史就是不斷優化的歷史，你可以從下圖看到它是如何一點點超過 HPHPc 的：

　　值得一提的是在 Android 4.4 中新的虛擬機 ART 就采用的是 AOT 方案（還記得么？前面提到的 HPHPc 就是這種），結果比之前使用 JIT 的 Dalvik 快了一倍，所以說 JIT 也不一定比 AOT 快。

　　因此這個項目是有很大風險的，如果沒有強大的內心和毅力，極有可能半途而廢。Google 就曾經想用 JIT 提升 Python 的性能，但最終失敗了，對于 Google 來說用到 Python 的地方其實并沒什么性能問題（好吧，以前 Google 是用 Python 寫過 crawl [參考 In The Plex]，但那都是1996年的事情了）。

　　比起 Google，Facebook 顯然有更大的動力和決心，PHP 是 Facebook 最重要的語言，我們來看看 Facebook 都投入了哪些大牛到這個項目中（不全）：

• Andrei Alexandrescu，『Modern C++ Design』和『C++ Coding Standards』的作者，C++ 領域無可爭議的大神
• Keith Adams，負責過 VMware 核心架構，當年 VMware 就派他一人去和 Intel 進行技術合作，足以證明在 VMM 領域他有多了解了
• Drew Paroski，在微軟參與過 .NET 虛擬機開發，改進了其中的 JIT。
• Jason Evans，開發了 jemalloc，減少了 Firefox 一半的內存消耗。
• Sara Golemon，『Extending and Embedding PHP』的作者，PHP 內核專家，這本書估計所有 PHP 高手都看過吧，或許你不知道其實她是女的

　　雖然沒有像 Lars Bak、Mike Pall 這樣在虛擬機領域的頂級專家，但如果這些大牛能齊心協力，寫個虛擬機還是問題不大的，那么他們將面臨什么樣的挑戰呢？接下來我們一一討論。

　　規范是什么？

　　自己寫 PHP 虛擬機要面臨的第一個問題就是 PHP 沒有語言規范，很多版本間的語法還會不兼容（甚至是小版本號，比如 5.2.1 和 5.2.3），PHP 語言規范究竟如何定義呢？來看一篇來自 IEEE 的說法：

The PHP group claim that they have the final say in the specification of (the language) PHP. This groups specification is an implementation, and there is no prose specification or agreed validation suite.

　　所以唯一的途徑就是老老實實去看 Zend 的實現，好在 HPHPc 中已經痛苦過一次了，所以 HHVM 能直接利用現成，因此這個問題并不算太大。

　　語言還是擴展？

　　實現 PHP 語言不僅僅只是實現一個虛擬機那么簡單，PHP 語言本身還包括了各種擴展，這些擴展和語言是一體的，Zend 不辭辛勞地實現了各種你可能會用到的功能。如果分析過 PHP 的代碼，就會發現它的 C 代碼除去空行注釋后居然還有80+萬行，而你猜其中 Zend 引擎部分有多少？只有不到10萬行。

　　對于開發者來說這不是什么壞事，但對于引擎實現者來說就很悲劇了。我們可以拿 Java 來進行對比，寫個 Java 的虛擬機只需實現字節碼解釋及一些基礎的 JNI 調用，Java 絕大部分內置庫都是用 Java 實現的。所以如果不考慮性能優化，單從工作量看，實現 PHP 虛擬機比 JVM 要難得多，比如就有人用8千行的 TypeScript 實現了一個 JVM Doppio。

　　而對于這個問題，HHVM 的解決辦法很簡單，那就是只實現 Facebook 中用到的，而且同樣可以先用 HPHPc 中之前寫過的，所以問題也不大。

　　實現 Interpreter

　　接下來是 Interpreter 的實現，在解析完 PHP 后會生成 HHVM 自己設計的一種 Bytecode，存儲在~/.hhvm.hhbc（SQLite 文件） 中以便重用，在執行 Bytecode 時和 Zend 類似，也是將不同的字節碼放到不同的函數中去實現（這種方式在虛擬機中有個專門的稱呼：Subroutine threading）

　　Interpreter 的主體實現在 bytecode.cpp 中，比如 VMExecutionContext::iopAdd 這樣的方法，最終執行會根據不同類型來區分，比如 add 操作的實現是在 tv-arith.cpp 中，下面摘抄其中的一小段：

if (c2.m_type == KindOfInt64)  return o(c1.m_data.num, c2.m_data.num);
if (c2.m_type == KindOfDouble) return o(c1.m_data.num, c2.m_data.dbl);

　　正是因為有了 Interpreter，HHVM 在對于 PHP 語法的支持上比 HPHPc 有明顯改進，理論上做到完全兼容官方 PHP。但僅這么做在性能并不會比 Zend 好多少，由于無法確定變量類型，所以需要加上類似上面的條件判斷語句，但這樣的代碼不利于現代 CPU 的執行優化。另一個問題是數據都是 boxed 的，每次讀取都需要通過類似 m_data.num 和m_data.dbl 的方法來間接獲取。

　　對于這樣的問題，就得靠 JIT 來優化了。

　　實現 JIT 及優化

　　首先值得一提的是 PHP 的 JIT 之前并非沒人嘗試過：

• 2008 年就有人用 LLVM 實驗過，結果還比原來慢了 21 倍。。。
• 2010 年 IBM 日本研究院基于他們的 JVM 虛擬機代碼開發了 P9，性能是官方 PHP 的 2.5 到 9.5 倍，可以看他們的論文Evaluation of a just-in-time compiler retrofitted for PHP。
• 2011 年 Andrei Homescu 基于 RPython 開發過，還寫了篇論文 HappyJIT: a tracing JIT compiler for PHP，但測試結果有好有壞，并不理想。

　　那么究竟什么是 JIT？如何實現一個 JIT？

　　在動態語言中基本上都會有個 eval 方法，可以傳給它一段字符串來執行，JIT 做的就是類似的事情，只不過它要拼接不是字符串，而是不同平臺下的機器碼，然后進行執行，但如何用 C 來實現呢？可以參考 Eli 寫的這個入門例子，以下是文中的一段代碼：

unsigned char code[] = {
  0x48, 0x89, 0xf8,                   // mov %rdi, %rax
  0x48, 0x83, 0xc0, 0x04,             // add $4, %rax
  0xc3                                // ret
};
memcpy(m, code, sizeof(code));

　　然而手工編寫機器碼很容易出錯，所以最好的有一個輔助的庫，比如的 Mozilla 的 Nanojit 以及 LuaJIT 的 DynASM，但 HHVM 并沒有使用這些，而是自己實現了一個只支持 x64 的（另外還在嘗試用 VIXL 來生成 ARM 64 位的），通過 mprotect 的方式來讓代碼可執行。

　　但為什么 JIT 代碼會更快？你可以想想其實用 C++ 編寫的代碼最終編譯出來也是機器碼，如果只是將同樣的代碼手動轉成了機器碼，那和 GCC 生成出來的有什么區別呢？雖然前面我們提到了一些針對 CPU 實現原理來優化的技巧，但在 JIT 中更重要的優化是根據類型來生成特定的指令，從而大幅減少指令數和條件判斷，下面這張來自 TraceMonkey 的圖對此進行了很直觀的對比，后面我們將看到 HHVM 中的具體例子：

　　HHVM 首先通過 interpeter 來執行，那它會在什么時候使用 JIT 呢？常見的 JIT 觸發條件有 2 種：

• trace：記錄循環執行次數，如果超過一定數量就對這段代碼進行 JIT。
• method：記錄函數執行次數，如果超過一定數量就對整個函數進行 JIT，甚至直接 inline。

　　關于這兩種方法哪種更好在 Lambada 上有個帖子引來了各路大神的討論，尤其是 Mike Pall（LuaJIT 作者） 、Andreas Gal（Mozilla VP） 和 Brendan Eich（Mozilla CTO）都發表了很多自己的觀點，推薦大家圍觀，我這里就不獻丑了。

　　它們之間的區別不僅僅是編譯范圍，還有很多細節問題，比如對局部變量的處理，在這里就不展開了

　　但 HHVM 并沒有采用這兩種方式，而是自創了一個叫 tracelet 的做法，它是根據類型來劃分的，看下面這張圖：

　　可以看到它將一個函數劃分為了 3 部分，上面 2 部分是用于處理 $k 為整數或字符串兩種不同情況的，下面的部分是返回值，所以看起來它主要是根據類型的變化情況來劃分 JIT 區域的，具體是如何分析和拆解 Tracelet 的細節可以查看Translator.cpp 中的 Translator::analyze 方法，我還沒空看，這里就不討論了。

　　當然，要實現高性能的 JIT 還需進行各種嘗試和優化，比如最初 HHVM 新增的 tracelet 會放到前面，也就是將上圖的 A 和 C 調換位置，后來嘗試了一下放到后面，結果性能提示了 14%，因為測試發現這樣更容易提前命中響應的類型

　　JIT 的執行過程是首先將 HHBC 轉成 SSA (hhbc-translator.cpp)，然后對 SSA 上做優化（比如 Copy propagation），再生成本地機器碼，比如在 X64 下是由 translator-x64.cpp 實現的。

　　我們用一個簡單的例子來看看 HHVM 最終生成的機器碼是怎樣的，比如下面這個 PHP 函數：

<?php
function a($b){
  echo $b + 2;
}

　　編譯后是這個樣子：

mov rcx,0x7200000
mov rdi,rbp
mov rsi,rbx
mov rdx,0x20
call 0x2651dfb <HPHP::Transl::traceCallback(HPHP::ActRec*, HPHP::TypedValue*, long, void*)>
cmp BYTE PTR [rbp-0x8],0xa
jne 0xae00306
; 前面是檢查參數是否有效

mov rcx,QWORD PTR [rbp-0x10]           ; 這里將 %rcx 被賦值為1了
mov edi,0x2                            ; 將 %edi（也就是 %rdi 的低32位）賦值為2
add rdi,rcx                            ; 加上 %rcx
call 0x2131f1b <HPHP::print_int(long)> ; 調用 print_int 函數，這時第一個參數 %rdi 的值已經是3了

; 后面暫不討論
mov BYTE PTR [rbp+0x28],0x8
lea rbx,[rbp+0x20]
test BYTE PTR [r12],0xff
jne 0xae0032a
push QWORD PTR [rbp+0x8]
mov rbp,QWORD PTR [rbp+0x0]
mov rdi,rbp
mov rsi,rbx
mov rdx,QWORD PTR [rsp]
call 0x236b70e <HPHP::JIT::traceRet(HPHP::ActRec*, HPHP::TypedValue*, void*)>
ret 

　　而 HPHP::print_int 函數的實現是這樣的：

void print_int(int64_t i) {
  char buf[256];
  snprintf(buf, 256, "%" PRId64, i);
  echo(buf);
  TRACE(1, "t-x64 output(int): %" PRId64 "\n", i);
}

　　可以看到 HHVM 編譯出來的代碼直接使用了 int64_t，避免了 interpreter 中需要判斷參數和間接取數據的問題，從而明顯提升了性能，最終甚至做到了和 C 編譯出來的代碼區別不大。

　　需要注意：HHVM 在 server mode 下，只有超過12個請求就才會觸發 JIT，啟動過 HHVM 時可以通過加上如下參數來讓它首次請求就使用 JIT：

-v Eval.JitWarmupRequests=0

　　所以在測試性能時需要注意，運行一兩次就拿來對比是看不出效果的。

　　類型推導很麻煩，還是逼迫程序員寫清楚吧

　　JIT 的關鍵是猜測類型，因此某個變量的類型要是老變就很難優化，于是 HHVM 的工程師開始考慮在 PHP 語法上做手腳，加上類型的支持，推出了一個新語言 - Hack（吐槽一下這名字真不利于 SEO），它的樣子如下：

<?hh
class Point2 {
  public float $x, $y;
  function __construct(float $x, float $y) {
    $this->x = $x;
    $this->y = $y;
  }
}
//來自：https://raw.github.com/strangeloop/StrangeLoop2013/master/slides/sessions/Adams-TakingPHPSeriously.pdf

　　注意到 float 關鍵字了么？有了靜態類型可以讓 HHVM 更好地優化性能，但這也意味著和 PHP 語法不兼容，只能使用 HHVM。

　　其實我個人認為這樣做最大的優點是讓代碼更加易懂，減少無意的犯錯，就像 Dart 中的可選類型也是這個初衷，同時還方便了 IDE 識別，據說 Facebook 還在開發一個基于 Web 的 IDE，能協同編輯代碼，可以期待一下。

　　你會使用 HHVM 么？

　　總的來說，比起之前的 HPHPc，我認為 HHVM 是值得一試的。它是真正的虛擬機，能夠更好地支持各種 PHP 的語法，所以改動成本不會更高，而且因為能無縫切換到官方 PHP 版本，所以可以同時啟動 FPM 來隨時待命，HHVM 還有FastCGI 接口方便調用，只要做好應急備案，風險是可控的，從長遠來看是很有希望的。

　　性能究竟能提升多少我無法確定，需要拿自己的業務代碼來進行真實測試，這樣才能真正清楚 HHVM 能帶來多少收益，尤其是對整體性能提升到底有多少，只有拿到這個數據才能做決策。

　　最后整理一下可能會遇到的問題，有計劃使用的可以參考：

• 擴展問題：如果用到了 PHP 擴展，肯定是要重寫的，不過 HHVM 擴展寫起來比 Zend 要簡單的多，具體細節可以看 wiki 上的例子。
• HHVM Server 的穩定性問題：這種多線程的架構運行一段時間可能會出現內存泄露問題，或者某個沒寫好的 PHP 直接導致整個進程掛掉，所以需要注意這方面的測試和容災措施。
• 問題修復困難：HHVM 在出現問題時將比 Zend 難修復，尤其是 JIT 的代碼，只能期望它比較穩定了。

　　P.S. 其實我只了解基本的虛擬機知識，也沒寫過幾行 PHP 代碼，很多東西都是寫這篇文章時臨時去找資料的，由于時間倉促水平有限，必然會有不正確的地方，歡迎大家評論賜教 :)

　　2014年1月補充：目前 HHVM 在鄙廠的推廣勢頭很不錯，推薦大家在 2014年 嘗試一下，尤其是現在兼容性測試已經達到98.58%了，修改成本進一步減小。

　　引用

• Andrei Alexandrescu on AMA
• Keith Adams 在 HN 上的蛛絲馬跡
• How Three Guys Rebuilt the Foundation of Facebook
• PHP on the Metal with HHVM
• Making HPHPi Faster
• HHVM Optimization Tips
• The HipHop Virtual Machine (hhvm) PHP Execution at the Speed of JIT
• Julien Verlaguet, Facebook: Analyzing PHP statically
• Speeding up PHP-based development with HHVM
• Adding an opcode to HHBC