最近兩年我對 gc 很感興趣 :D 已經(jīng)在項(xiàng)目中用了兩年。項(xiàng)目從 C++ 轉(zhuǎn)到 C ，gc 模塊的實(shí)現(xiàn)發(fā)生了變化，但是本質(zhì)卻沒有變。我對 C++ 加入 gc 是非常歡迎的，這點(diǎn)在以前寫的另一篇 blog 中已經(jīng)表明過態(tài)度。
記得兩年前，當(dāng)有機(jī)會(huì)當(dāng)面問 Bjarne Stroustrup 關(guān)于 C++ 發(fā)展的問題時(shí)，我毫不猶豫的講出自己對 gc 的迫切期待，并希望能夠以最小代價(jià)的把 gc 加入 C++ 。因?yàn)橐呀?jīng)實(shí)現(xiàn)過一些 C++ 的 gc 模塊，我有一些語言上的需求。當(dāng)時(shí)描述了自己的想法，可惜英文實(shí)在是太差了，完全說不清楚 :( 因?yàn)闆]聽明白我的意思，Bjarne Stroustrup 他老人家似乎也很無奈，最后只是建議中國的程序員應(yīng)該參于到語言的標(biāo)準(zhǔn)化事務(wù)當(dāng)中去，一直以來，C++ 標(biāo)準(zhǔn)委員會(huì)中似乎沒有來至中國大陸的程序員。
既然 C++ 是你的工具，你就應(yīng)該努力把自己對工具的改進(jìn)需求說出來。
其實(shí)我的需求很簡單，就是 C++ 中應(yīng)該加入一些對數(shù)據(jù)結(jié)構(gòu)中數(shù)據(jù)類型的有限描述。其實(shí)只做內(nèi)存管理的話，類型信息只需要區(qū)分?jǐn)?shù)據(jù)還是指針就夠了。具體數(shù)據(jù)類型可以忽略。
我的想法就是像虛表一樣，給每個(gè)類多加一張表，描述這個(gè)對象中指針的位置(記錄一個(gè)偏移量)。由于 C++ 的對象布局比較復(fù)雜，這個(gè)工作如果不在編譯器里做，會(huì)相當(dāng)麻煩。有這樣的信息，gc 就可以容易的遍歷內(nèi)存了?？茨瞧恼碌慕榻B，C++ 的 gc 似乎用 gc_strict gc_relax 這樣的關(guān)鍵字來描述一整塊內(nèi)存區(qū)內(nèi)有沒有指針，而沒有更細(xì)致的精確到每個(gè)數(shù)據(jù)上。這跟已有的 C 的 gc 庫 實(shí)現(xiàn)類似。我猜測這些是為了兼容 POD 類型設(shè)計(jì)的，對于 C++ 自己的類，應(yīng)該可以更好的解決。畢竟編譯器知道全部的類型信息。
除此之外，遍歷堆棧依舊是個(gè)問題，但已經(jīng)好多了。遍歷可以用各種語法糖來實(shí)現(xiàn)，反正 C++ 有了 template 后，什么詭異的寫法都弄的出來。
最后說兩句 gc 的效率問題。gc 沒有人肉內(nèi)存管理效率高是一種普遍的誤解。如果不是靠臆測，而是自己實(shí)現(xiàn)一個(gè) gc 模塊，然后做代碼剖析的話，很容易相信 gc 可以帶來更高的性能。關(guān)于 gc 和人肉內(nèi)存管理之間的性能話題，以前寫過太多，吵的太多，嚼著都沒味道了。
記得兩年前，當(dāng)有機(jī)會(huì)當(dāng)面問 Bjarne Stroustrup 關(guān)于 C++ 發(fā)展的問題時(shí)，我毫不猶豫的講出自己對 gc 的迫切期待，并希望能夠以最小代價(jià)的把 gc 加入 C++ 。因?yàn)橐呀?jīng)實(shí)現(xiàn)過一些 C++ 的 gc 模塊，我有一些語言上的需求。當(dāng)時(shí)描述了自己的想法，可惜英文實(shí)在是太差了，完全說不清楚 :( 因?yàn)闆]聽明白我的意思，Bjarne Stroustrup 他老人家似乎也很無奈，最后只是建議中國的程序員應(yīng)該參于到語言的標(biāo)準(zhǔn)化事務(wù)當(dāng)中去，一直以來，C++ 標(biāo)準(zhǔn)委員會(huì)中似乎沒有來至中國大陸的程序員。
既然 C++ 是你的工具，你就應(yīng)該努力把自己對工具的改進(jìn)需求說出來。
其實(shí)我的需求很簡單，就是 C++ 中應(yīng)該加入一些對數(shù)據(jù)結(jié)構(gòu)中數(shù)據(jù)類型的有限描述。其實(shí)只做內(nèi)存管理的話，類型信息只需要區(qū)分?jǐn)?shù)據(jù)還是指針就夠了。具體數(shù)據(jù)類型可以忽略。
我的想法就是像虛表一樣，給每個(gè)類多加一張表，描述這個(gè)對象中指針的位置(記錄一個(gè)偏移量)。由于 C++ 的對象布局比較復(fù)雜，這個(gè)工作如果不在編譯器里做，會(huì)相當(dāng)麻煩。有這樣的信息，gc 就可以容易的遍歷內(nèi)存了?？茨瞧恼碌慕榻B，C++ 的 gc 似乎用 gc_strict gc_relax 這樣的關(guān)鍵字來描述一整塊內(nèi)存區(qū)內(nèi)有沒有指針，而沒有更細(xì)致的精確到每個(gè)數(shù)據(jù)上。這跟已有的 C 的 gc 庫 實(shí)現(xiàn)類似。我猜測這些是為了兼容 POD 類型設(shè)計(jì)的，對于 C++ 自己的類，應(yīng)該可以更好的解決。畢竟編譯器知道全部的類型信息。
除此之外，遍歷堆棧依舊是個(gè)問題，但已經(jīng)好多了。遍歷可以用各種語法糖來實(shí)現(xiàn)，反正 C++ 有了 template 后，什么詭異的寫法都弄的出來。
最后說兩句 gc 的效率問題。gc 沒有人肉內(nèi)存管理效率高是一種普遍的誤解。如果不是靠臆測，而是自己實(shí)現(xiàn)一個(gè) gc 模塊，然后做代碼剖析的話，很容易相信 gc 可以帶來更高的性能。關(guān)于 gc 和人肉內(nèi)存管理之間的性能話題，以前寫過太多，吵的太多，嚼著都沒味道了。