0x0

前些天組里老司機@梁希在jvm的項目榨干機器性能之余，為了檢查下gcc編譯器和Intel Xoen CPU的正確性，寫了一組測試代碼測試了下mfence指令的效果

`
mfence Opcode : 0F AE /6

Performs a serializing operation on all load-from-memory and store-to-memory instructions that were issued prior the MFENCE instruction. This serializing operation guarantees that every load and store instruction that precedes in program order the MFENCE instruction is globally visible before any load or store instruction that follows the MFENCE instruction is globally visible. The MFENCE instruction is ordered with respect to all load and store instructions, other MFENCE instructions, any SFENCE and LFENCE instructions, and any serializing instructions (such as the CPUID instruction).
Weakly ordered memory types can be used to achieve higher processor performance through such techniques as out-of-order issue, speculative reads, write-combining, and write-collapsing.
The degree to which a consumer of data recognizes or knows that the data is weakly ordered varies among applications and may be unknown to the producer of this data. The MFENCE instruction provides a performance-efficient way of ensuring load and store ordering between routines that produce weakly-ordered results and routines that consume that data.
It should be noted that processors are free to speculatively fetch and cache data from system memory regions that are assigned a memory-type that permits speculative reads (that is, the WB, WC, and WT memory types). The PREFETCHh instruction is considered a hint to this speculative behavior. Because this speculative fetching can occur at any time and is not tied to instruction execution, the MFENCE instruction is not ordered with respect to PREFETCHh instructions or any other speculative fetching mechanism (that is, data could be speculatively loaded into the cache just before, during, or after the execution of an MFENCE instruction).
`

簡單來說就是一個可以在CPU亂序執(zhí)行中保證真實的load/store順序的指令

0x1
老司機寫了一個小程序(注：有誤版)
// file: order.c

大概邏輯是： 一共有3個變量，v1.i, v2.i, b ,起了2個線程，一個順序寫入v1和v2，一個讀v1和v2，互相通過改變b的值來通訊，然后兩個線程不停循環(huán)。

這個程序會掛在
printf("assert error, cnt = %d, icnt = %d, i1 = %d, i2 = %d\n", cnt, icnt, i1, i2); 
這條斷言上，意思是線程1在順序寫入v1和v2，但是主線程卻出現(xiàn)讀到 v1=0，v2=1的情況。

0x2

然后我?guī)兔θタ戳艘幌拢X得這種寫法甚是粗暴，于是原樣照搬了一個c++11版:

因為是原樣照搬，所以肯定還是會掛，但是畢竟語義上更好理解了

我們先來分析一下為什么會掛

• 線程1對于v1，v2的寫入順序一定是一致的
• Memory Barrier也保證了他們寫入順序對其他線程的可見性（很有迷惑性的一點）
• 但是主線程卻可以讀到 v1=0,v2=1的情況
• 所以情況就是雖然順序寫入了，但是別的線程沒有看到正確的順序？
• Intel: 并不是！
• 原因是搞錯了因果關系，他真正保證的順序是當你讀到v2的new value的時候，那么v1也一定被寫入了。
• 解決方案就是互換上面代碼中我用**星號**標注出的兩行
• done

在舊寫法中，掛掉的情況是線程1寫入v1 = 1，主線程讀v1，沒有讀到，那么主線程認為v1是0，然后線程1繼續(xù)寫入v2，主線程讀到了，主線程認為v2是1。 然后掛在了斷言上。

兩行互換后，主線程首先讀取v2，如果v2已經(jīng)是1了，那么v1也一定是1，反之亦然。

0x3

當然，想讓跑通那個例子不需要那么多的atomic<>，精簡之后利用c++11的memory_order可以寫成如下：

利用變量b在兩個線程之間同步，如下圖

我們查看下生成的代碼
g++ -std=c++11 -pthread -g -O2 order.cpp

看來Intel的Strong Memory Model已經(jīng)保證了這一點，Memory Barrier都不需要了

（雖然標題里面有MemoryBarrier，但是內(nèi)容里面根本沒涉及的樣子。。）

序言

雖然nginx+lua開發(fā)一些小的web服務簡單快捷，但是由于種種原因，配套的工具比較缺乏，監(jiān)控工具和性能檢測工具等等。而且lua作為一種跑在虛擬機的腳本語言，雖然做的短小精悍，但是。。。功能和可調(diào)優(yōu)的空間還是欠缺了點。

前段時間使用春哥的systemtap腳本對我的lua服務做了下性能測試，這里記錄一下折騰的歷程

準備

systemtap是一個性能檢測和調(diào)試跟蹤的工具，最開始是為了調(diào)試內(nèi)核被做出來的，后來添加了用戶態(tài)跟蹤的功能。

折騰記錄

春哥的腳本要求systemtap2.2以上，公司測試服務器自帶的systemtap腳本的版本那是1.6，遠遠不夠，所以必須手動編譯一個。下載systamtap的源碼，然后./configuare + make就可以直接編了。最開始碰到的問題是公司el5系統(tǒng)的服務器的elfutil版本太低，得自己編譯一個高版本的elfutil然后指定路徑。。。。我怕麻煩，就把一個空的測試機器重裝成el6，elfutil的版本立馬就夠了(我真是太機智了)。

順利編譯出systamtap之后(中途遇到了systemtap版本不夠新導致的符號找不到的bug)，就是tengine的安裝，時間都折騰在這上面了。。。我們項目用的是tengine-ads這個版本，直接用tengine缺少模塊，就請了tengine組的同學幫忙把模塊給打了進去。由于要跟蹤lua內(nèi)部，所以自帶的luajit必須-g編譯。那邊的同學比較忙，我就只能自己要了服務器權限跑上去自己編，編了幾次之后那個測試服務器竟然磁盤滿了。。。總之就是折騰了一晚上和一早上，終于把帶debuginfo的tengine給裝上了。

效果

啟動tengine服務，把壓測程序開好，運行

./ngx-sample-lua-bt -p 29237 --luajit20 -t 200 -a '--vp 02 -R /home/wenqian.peiwq/systemtap-2.6/runtime -DSTP_NO_OVERLOAD --all-modules -DMAXSKIPPED=1024 ' > tmp.bt 

采樣結束后，利用brendangregg的FlameGraph tools可以繪制棧調(diào)用的火焰圖，如下：

通過這個圖，先是立馬發(fā)現(xiàn)了一個低級錯誤。。。（上面貼的圖上已經(jīng)沒了），我有很多打印debug的語句，用了這類用法

_log.log("debug", "xxx", util.print_r(some_data)) 

忘記了lua的求值策略，雖然debug下的這個語句在生產(chǎn)環(huán)境中不執(zhí)行，但是由于求值策略，util.print_r(some_data)仍然會先求值，導致了很大的性能損失，接近1/4。

同時也發(fā)現(xiàn)了UUID的生成所占用的時間也過分的長了一些，然后重寫了這個方法，使用了resty.string庫中的random模塊(直接調(diào)用了ngx_*的C函數(shù))，然后利用systemtap對比了前后的時間，提升了360%多，可見還是很有效果的。

注:

這個項目是基于我上次手擼的小框架dodolu，根據(jù)這次的測試結果，框架的封裝對我的項目造成的性能損失在1%以下。

背景

前段時間項目需要一個點擊服務，大致是要根據(jù)用戶請求的url及數(shù)據(jù)庫中的規(guī)則，匹配出一個結果并記錄日志。最開始是一個很小的需求，結果業(yè)務越來越復雜，業(yè)務邏輯中經(jīng)常要處理header頭和一些其他的信息，導致代碼越來越混亂。在一期結束之后，抽時間把這段時間的工作抽象出了一個輕量級框架，只做了適量的封裝，加入了代碼生成的模塊，可以幫助開發(fā)者迅速做出一個可用的web服務。

介紹

dodolu框架地址(Github)。

該框架只做了最小化的封裝，幾乎沒有性能損失，并提供了根據(jù)配置文件(meta.lua)，自動生成route模塊，nginx.conf配置，logger模塊的功能，減輕了開發(fā)工作量，避免重復手寫大量易錯的配置或字符串變量，有助于多人開發(fā)統(tǒng)一風格。

詳情Github的README

功能

包括三個部分，一個是web框架，一個是代碼自動生成模塊，一個是魔改出的lua遠程調(diào)試器。

web框架部分

只有1k行以下的代碼，集成了resty.template、resty.cookie、UUID生成等第三方模塊。提供request、response、context、util等庫方便開發(fā)人員使用。

代碼自動生成部分

可自動生成:

1. 路由配置
2. 日志記錄模塊
3. nginx.conf

主要目的在于解決nginx配置與lua代碼的分離問題(在日志記錄中尤為嚴重)。

開發(fā)人員新建應用步驟：在App文件夾下，新建lua文件，然后填入do_get()方法即可處理相應的get請求，所有配置在meta/meta.lua里面。

一個記錄日志并返回1x1gif的例子：

-- 這個文件下面存放你的業(yè)務邏輯

-- 這個文件下面存放你的業(yè)務邏輯

local app = {}
function app.do_get(ctx) 
    local response = ctx.response
    local request = ctx.request
    local cookie = ctx.cookie

    response:set_content_type("text/html")
    local url = request.uri
    -- do some process

    ------------- write log ---------------
    -- my_log 日志模塊是根據(jù)meta.lua自動生成的
    local logger = ctx.get_logger('my_log')  
    local log_data = { a = "xxx"}
    logger.write(log_data, other_params)

    ------------- return empty gif -------
    response:empty_gif()
    response:close()
end

function app.do_post(ctx) end
function app.do_put(ctx) end
function app.do_delete(ctx) end

return app

lua遠程調(diào)試器

文檔詳細見這里，這里只演示下用法：
sh debug.sh，然后運行用戶程序，成功后

下一步  n



查看源碼  l

設置斷點   b <file>:<line>   查看    listb



查看局部變量  local

> local
{
        ["tab"] = {
                {
                        ["bar"] = 2,
                        ["foo"] = 1,
                },
                "table: 0x2589ee0",
        },
}

查看變量   p tab



繼續(xù)執(zhí)行，直到斷點  r

> r
Paused at file a.lua line 11

本人博客地址（http://m.shnenglu.com/pwq1989/）
     摘要: 序類型系統(tǒng)在編程語言中是極為重要，不單單是提供一個類型的標注或是方便編譯，更多時候是減少出錯的可能。當類型系統(tǒng)強大到一定程度，就可以進行所謂的“富類型編程”，比如在Haskell中只要編譯器不報錯，大致上程序也是沒什么bug的。在常用的靜態(tài)類型語言中，C++/java/C#等，雖然在新標準與新版本中支持類型的自動推導，但是對類型系統(tǒng)及其推導還是缺少更為直接的支持。很多常用語...  閱讀全文

本人博客地址：http://m.shnenglu.com/pwq1989/ 

昨天在知乎上看到一個評論提到了Haskell的YC實現(xiàn)，就去搜了一下，然后就看到了一個實現(xiàn)：

嗯，真是別扭

反觀一下其他語言的YC寫法，就貼一個lua的把
雖然看起來很長，但是容易理解的多，用λ表達式寫出來就是（wiki）
λf. (λx. f (x x)) (λx. f (x x))
目的就是能做出 Y f = f (Y f) 這種效果，之所以這么寫，是為了不引入名字（引入了名字是惡!）

對于Haskell這種用HM類型系統(tǒng)的語言來說，最大的問題就是不能遞歸的定義類型，同樣是靜態(tài)類型檢查，比如C#，就可以不費力的用Func和delegate做出來，haskell 額，就得扭曲的利用newtype Mu a = Mu (Mu a -> a) 來繞過類型檢查（當然，這個在Haskell中是不可能構造出一個實際的值的）。

看下他是怎么做的，我們來把他展開一下：
原式子：y f = (\h -> h $ Mu h) (\x -> f . (\(Mu g) -> g) x $ x)
帶進去：y f = (\x -> f . (\(Mu g) -> g) x $ x) $ Mu (\x -> f . (\(Mu g) -> g) x $ x)
再來一遍：y f = f . (\x -> f . (\(Mu g) -> g) x $ x) $ Mu (\x -> f . (\(Mu g) -> g) x $ x)

這樣子，最后那個式子的f. 后面的那部分，提取 (\x -> f . (\(Mu g) -> g) x $ x) 這個公因式 就相當于是(\h -> h $ Mu h) (\x -> f . (\(Mu g) -> g) x $ x)了（很像數(shù)學把，但也沒多大關系）
最后，就可以做出y f = f . (y f)了。

其實這個寫法最關鍵的是 newtype Mu a = Mu (Mu a -> a)的作用，他是如何繞過類型檢查，但是又不在運行期構造一個值（想構造也構造不出來）。

來看下他的類型推導過程，y的類型是y :: (a -> a) -> a，所以里面f就是 f :: a -> a，所以f . (\(Mu g) -> g) x $ x 這個式子可以推出里面的x是 x :: Mu a 然后(\(Mu g) -> g) x 取出里面的 a，這樣就成了
f a $ Mu a，這時候Mu a = Mu (Mu a -> a) 遞歸定義的作用就發(fā)揮了，為了類型的推導，繼續(xù)將那個紅色的a 推導成 Mu a -> a，這樣 f (Mu a -> a) 會返回一個Mu a -> a，管他叫f'把，這樣 f' (Mu a) 就返回一個 a。有根據(jù)前面的(\h -> h $ Mu h) 繼續(xù)講上面提到的a變成 Mu a -> a。就是把Mu a 喂給了 (Mu a -> a)，最后還是返回一個a。
(>_< 其實上面這段是我編出來的，我編不下去了，我不知道ghc是怎么做這個事情的，等我有生之年看完slpj-book-1987再想想)

我們來應用一下，返回一個階乘：

本人博客地址：http://m.shnenglu.com/pwq1989/ 


今天群里姐夫推薦了個C++的Actor框架 Theron，就看了下源碼，注釋比代碼還多，業(yè)界良心。

源碼我還沒看完，就看到了他的一個叫StringPool的類，里面通過Ref來生成單例（Singleton），看了下

我們先不討論這一段代碼，先看看下面的：

大家如果看過C++的Double Check Lock不可靠的這篇paper(地址)，作者給出的解決方案是這樣的：

其實這兩個Memory Barrier不用全屏障，第一個用讀屏障rmb()就好了。第二個需要一個寫屏障wmb()。

我們都知道m(xù)b這個東西是為了防止CPU級別的指令亂序被發(fā)明出來的，（另一個是編譯器級別的，和本篇文章沒有多大關系，有興趣大家可以去研究下），實現(xiàn)也是由平臺相關的特殊指令(mfence這樣的)組成的。

之所以要寫成這樣，第二個mb()是為了防止在構造函數(shù)完成之前提前對目標賦值，但ctor還沒完成，就被掛起，然后第二個線程訪問的時候，認為已經(jīng)構造完畢，進而使用不完整的數(shù)據(jù)引發(fā)奇怪的錯誤。

(第一個rmb()的作用我覺得是可有可無，加上可能是為了效率把（猜），強制刷新讀取instance_的值，防止進入第一個check去競爭那個鎖，不加也是不會有錯的，因為POSIX規(guī)定mutex之間必須保持內(nèi)存的可見性，所以是不需要擔心讀到臟數(shù)據(jù)) <-- 這段是個人意見，歡迎修正。

下面就是我趴了半下午才想明白的問題。。。為啥Theron中那段代碼（第一段代碼）不需要在lock中添加mb()，后來往下翻了下，發(fā)現(xiàn)StringPool的構造函數(shù)是空的。。根本就沒有內(nèi)存的寫入，當然就不需要wmb()了。


可見，C++的多線程編程，好難

本人博客地址：http://m.shnenglu.com/pwq1989/

上一篇對Luajit的代碼結構和編譯過程做了簡單的描述，這一篇就講一下buildvm在第一步預處理dasc文件的過程和DynASM這個輪子。

官方連接：http://luajit.org/dynasm.html

是為了讓你更優(yōu)雅的C里面擼匯編的一個工具，我記得以前看過一個老外的blog對比過同樣功能的jit code generator的語法，Luajit的作者顯然品位還是很高的。

我們先來看看如果不用工具硬生生擼代碼的話會發(fā)生什么。
1、你往一段內(nèi)存里面寫0xB8,0x00,0x01....
2、你在文件里定義好多l(xiāng)abel，寫個copy section的宏往內(nèi)存里面復制，你還不能確定里面到底是什么。（哦。。這個的術語叫Threaded。。。）

然后再對比下AsmJit或者Xbyak的例子看看（他們的功能差不多），DynASM還提供了.marco實現(xiàn)，就會發(fā)現(xiàn)語法真是sweeeet~

這是我寫著玩的一個草泥馬語jit解釋器（https://github.com/pwq1989/GMHjit）語法真是清新自然啊，如果你想看工業(yè)級的應用，可以看看Google的Haberman寫的protobuf的upb庫，里面用DynASM進行了jit，號稱快了多少多少（不去考證了），或者是agentzh寫的sregex正則庫，也是用它做了jit。一般來說DSL配上jit的話一定會快很多就錯不了了。

下面給一個DynASM的Demo程序（摘抄自這個blog）

預處理之后那就會變成這樣子：
dasm_put就是把num參數(shù)和actions[]一起放入了Dst（#define Dst &state）的制定的內(nèi)存中，這時候已經(jīng)是機器碼的形式了。
下面是對于acitons[]數(shù)組內(nèi)容的解釋：
184(B8)-- mov eax, [immediate] 指令的第一個字節(jié)
237       -- 內(nèi)置的標志DASM_IMM_D, 指明應該放入一個4字節(jié)寬度的參數(shù)，與上一條指令完成一個MOV
195(C3)-- 對應ret指令
255       -- 內(nèi)置的標志DASM_STOP

以上就是最簡單的例子，dasm_growpc()是內(nèi)置的函數(shù)，用來增長maxpc, 這樣在程序里面就可以方便寫出jmp => label 這樣的指令了。

由于DynASM的文檔很少，幸虧還有幾個例子，除了例子唯一能看的就是源碼了，所以在用的時候出現(xiàn)問題是很痛苦的。。當時寫GMHjit就發(fā)現(xiàn)了蛋疼的pre-process period bug，后來繞過去了。

源碼文件有這么幾個
-- dynasm.lua
-- dynasm_proto.h
-- dynasm_*.lua
-- dynasm_*.h  // * x64  x86  ppc mips arm 等target

用起來就是lua dynasm.lua a.dasm > a.h 

下面就從dynasm.lua開始分析下他的源碼

入口是parseargs函數(shù)，里面給的g_opt參數(shù)賦默認的值，一個repeat 中調(diào)用parseopt解析參數(shù)，opt_map就是option對args的函數(shù)映射。

函數(shù)wline，wcomment，wsync，wdumplines都是對輸出的目標文件的操作。

真正的主函數(shù)是 translate，把input file變成 output file，在readfile中的doline函數(shù)是真正的處理過程，里面判斷是否是Assembler line之后Emit C code，調(diào)用dostmt(aline)。里面繼續(xù)有map_coreop[*]來處理section macro arch nop_ error_1 include  if endif elseif 等關鍵字，想深入研究的可以自己去看，其中在loadarch中根據(jù)arch加載不同的lua庫

如果arch是x64的話，本質(zhì)還是require x86
來看dasm_x86.lua文件

里面提供了很多dump方法，可以供我們遇到問題時候調(diào)試處理過程。

表明了代表的參數(shù)和長度等信息。
這個文件里面所有的函數(shù)就是做了一件事，把你的 |...  這樣子的代碼處理成數(shù)組輸出到目標文件中（我是匯編渣渣，里面貌似支持SSE2、3、4+，看不懂，等到以后看到traced jit的時候再去翻手冊把）

預處理完成之后，就是#include "dasm_x86.h"，里面有最關鍵的dasm_State結構體的定義，幾乎里面所有的函數(shù)都是對外的API，有init,setup,free等等，除去初始化與free之外，有三個步驟是需要出現(xiàn)在你都代碼中：
1、dasm_put(Dst,...) 這個是自動生成的，不用我們操心，根據(jù)actionlist[]和運行時的參數(shù)寫入到Dst指定的內(nèi)存（Dst->section）中.
2、dasm_link() 第二個參數(shù)是返回的代碼長度大小，這個函數(shù)把section合并到一起，處理偏移等等。
3、dasm_encode() 第二個參數(shù)是一個接受encode輸出的buffer指針。

然后就可以用一個函數(shù)指針，比如聲明一個 int (*f)(*int), int ret = f(param) 直接運行剛剛生成的機器碼了。

本人博客地址：http://m.shnenglu.com/pwq1989/

第一篇對Luajit做一個大概的介紹，我目前也正在慢慢的讀通源碼中，以后發(fā)現(xiàn)了新東西就補充在這里。

大家可以從官網(wǎng)下載到源碼（http://luajit.org/），也可以從Github（https://github.com/LuaDist/luajit）down下來，順便還可以看下commit記錄。

大家對著luajit的wiki結合源碼看的話會更好些，因為。。文檔太特么少了！！

目錄結構：
-- src
    -- host
    -- jit
    *.c
    *.h
    *.dasc
等等，別的不是很重要

最開始我是從main函數(shù)開始看的，然后。。碰了一鼻子灰，后來研究下他的makefile，發(fā)現(xiàn)他是這樣子的編譯的，貼一下關鍵的msvcbuild.bat的代碼（這個更容易看懂）

先創(chuàng)建了一個buildvm.exe的中間工具，來自動生成代碼，分別生成了lj_vm.obj，lj_bcdef.h，lj_ffdef.h ，lj_recdef.h ，jit\vmdef.lua，lj_folddef.h， lj_libdef.h

其中l(wèi)v_vm.obj是依賴于host\buildvm_arch.h的，這個是用DynASM預處理vm_x86.dasc生成的，這個工具的具體分析會在下一篇博客提及。

先來看下上面自動生成的代碼：
lj_bcdef.h:

lj_bc_ofs[]可能是bc在vm代碼段中的偏移量（這個我還沒深入進去調(diào)試一下），vm的一部分是用DynASM直接擼匯編擼出來的，wiki中也有提到下一步jit化的opcode等等。