• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 119  文章 - 290  trackbacks - 0

            博客搬家了哦,請移步
            叫我abc

            常用鏈接

            留言簿(12)

            隨筆分類

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 303655
            • 排名 - 84

            最新評論

            閱讀排行榜

            最近寫新項目,希望能從內存管理、指針引用的問題上前進一小步,于是在網上爬出云風以前寫的一個gc庫,姑且稱為yfgc吧
            粗看了一下接口,很少很正交,使用例子也非常簡單。只是我對垃圾收集的原理不是很熟悉,又或者這些接口太接近gc的底層原理,因此我并不是很確定如何運用這些接口。
            借用某句著名的話,“源碼面前,了無秘密”。為了了解如何運用這些接口,我決定去看看這個不到1000行的gc庫的源碼,順便寫些東西,畢竟好久沒寫了。

            yfgc的地址
            svn地址:http://manualgc.googlecode.com/svn/trunk

            撇去weak table和再分配不談,yfgc有以下接口
             1void gc_init();
             2void gc_exit();
             3
             4void gc_enter();
             5void gc_leave(void *p,);
             6
             7void* gc_malloc(size_t sz,void *parent,void (*finalizer)(void *));
             8
             9void gc_link(void *parent,void *prev,void *now);
            10void gc_collect();

            先看幾個明顯易懂的
            gc_init,一看就知道是初始化這個gc庫的,約摸著底下也就是初始化一些數據結構,分配一些初始內存等等。不過至于做了什么,以后再談。
            gc_exit,一看就知道是在程序退出時析構gc庫的,多半是釋放內存。如果實現不是很復雜的話,不調用這個函數也不會怎樣。
            gc_collect,一定是收集垃圾的了,不過現在就深入這個函數的話,一定是本末倒置。因為還不知道內存在哪里分配,就去看內存收集顯然是不對的。
            gc_malloc,可以肯定,這就是gc庫的內存分配接口了。好吧,先看看這個函數,我都有點迫不及待了。

            先看一下gc_malloc的三個參數
            1.sz,請求分配的內存大小
            2.parent,按字面意思是父親,如果用工廠模式做類比的話,也許會更容易理解些。工廠生產一個對象,就申請一塊內存,parent則是工廠本身。
            更通用和接近的解釋是,parent即持有或者用指針引用這塊新內存的那些對象。垃圾收集的概念就是,當一塊內存在程序里不被任何對象持有或者指針引用的時候,它就是一塊廢棄的內存,可以被系統回收。當有任何一個指針引用著這塊內存的時候,他就必然不能被回收。
            所以,parent這個參數,或者說,新分配的內存必須要比parent那塊內存活得更長久,因為parent擁有或者引用著這塊新分配的內存。
            3.finalizer,析構函數,如果分配內存用來實例化一個類的話,那么這塊內存要回收的時候,顯然要有一個時機來調用類的析構函數才行。這個回調函數正好可以完成這個任務。

            干脆寫一個yfgc的源碼解析系列好了

            posted on 2008-09-10 20:22 LOGOS 閱讀(4766) 評論(5)  編輯 收藏 引用 所屬分類: 垃圾收集

            FeedBack:
            # re: 垃圾收集的那點事(A) 2008-09-10 20:37 陳梓瀚(vczh)
            語言們用的垃圾收集器都不需要我們顯示collect而能夠在適當的時候【中斷程序】并【開始搜索并收集】。所以這個東西最多算個池。以前我見過一個可以在C++用的垃圾收集器,不用自己collect,他后臺自動執行了。

            這個gc看起來是讓你顯式地維護一個圖,然后手動對一定不能收集的節點進行標記,然后自己collect。算是【理論上】實現了那個功能。  回復  更多評論
              
            # re: 垃圾收集的那點事(A) 2008-09-10 21:10 Don't tell u
            研究win2k泄漏代碼里面的gc似乎也是一種方法,雖然不像.net java那么徹底,似乎夠用,^_^。  回復  更多評論
              
            # re: 垃圾收集的那點事(A) 2008-09-10 21:14 LOGOS
            @陳梓瀚(vczh)
            不錯,確實如你所說,這東西強迫人手動去維護依賴關系
            如果不這么做,就無法從中得到任何好處

            至于手動collect,在我看來和后臺自動collect無啥區別  回復  更多評論
              
            # re: 垃圾收集的那點事(A) 2008-09-10 22:45 陳梓瀚(vczh)
            還是有的,譬如new失敗的時候后臺可以中斷然后collect然后再幫你new。  回復  更多評論
              
            # re: 垃圾收集的那點事(A) 2008-09-11 15:49 空明流轉
            說實話我真覺得不比shared_ptr好多少,RAII才是C++一類貨的王道。  回復  更多評論
              
            中文字幕精品无码久久久久久3D日动漫| 欧美大香线蕉线伊人久久| 人妻无码久久一区二区三区免费| 青青草原综合久久大伊人导航| 狠狠色综合久久久久尤物| 欧美综合天天夜夜久久| 狠狠色丁香久久婷婷综| 欧美亚洲国产精品久久蜜芽| 日韩一区二区久久久久久 | 亚洲AV无码久久精品色欲| 女人高潮久久久叫人喷水| 国产一区二区久久久| 久久精品中文騷妇女内射| 伊人久久综合精品无码AV专区| 国产色综合久久无码有码| 色婷婷综合久久久中文字幕| 成人久久精品一区二区三区| 久久无码av三级| 无码8090精品久久一区| 亚洲国产另类久久久精品黑人| 奇米影视7777久久精品| 51久久夜色精品国产| 亚洲国产成人久久综合一区77| 亚洲精品美女久久777777| 国产精品久久久久9999| 久久综合伊人77777| 亚洲国产精品无码久久久不卡| 久久99国产精品久久久| 久久久久久久久久久免费精品| 久久久久久久久波多野高潮| …久久精品99久久香蕉国产| 久久国产精品一区| 久久精品无码午夜福利理论片| 久久精品国产只有精品66| 中文字幕人妻色偷偷久久| 国产成人99久久亚洲综合精品| 国内精品久久久久久99蜜桃| 久久精品亚洲乱码伦伦中文| 久久综合精品国产二区无码| 日韩va亚洲va欧美va久久| 久久精品人人做人人爽97|