• <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)

            隨筆分類

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 303611
            • 排名 - 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 閱讀(4764) 評論(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++一類貨的王道。  回復  更多評論
              
            亚洲精品无码久久毛片| 色偷偷88欧美精品久久久| 国产精品禁18久久久夂久| 国产精品一久久香蕉产线看| 久久精品国产影库免费看 | 久久亚洲色一区二区三区| 色婷婷久久综合中文久久一本| 伊人久久综合无码成人网| 中文字幕亚洲综合久久| 漂亮人妻被中出中文字幕久久| 国产成人精品白浆久久69| 色婷婷狠狠久久综合五月| 中文字幕久久精品无码| 久久精品国产亚洲精品| 2020久久精品国产免费| 久久久久久久免费视频| 狠狠精品久久久无码中文字幕| 国内精品伊人久久久久777| 国产L精品国产亚洲区久久| 久久久久久久久无码精品亚洲日韩| 欧美日韩中文字幕久久久不卡| 国产综合久久久久| 亚洲国产欧美国产综合久久| 亚洲国产香蕉人人爽成AV片久久| 7777久久亚洲中文字幕| 色8久久人人97超碰香蕉987| 思思久久好好热精品国产| 久久久久久噜噜精品免费直播| 久久精品国产99国产电影网| 国产精品久久一区二区三区| 精品少妇人妻av无码久久| 亚洲国产精品无码久久一线| 精品国产乱码久久久久久人妻| 精品国产91久久久久久久a| 久久香蕉国产线看观看乱码| 99国产精品久久久久久久成人热| 亚洲欧美日韩中文久久| 久久久婷婷五月亚洲97号色| 九九精品99久久久香蕉| 久久国产精品-国产精品| 久久久无码一区二区三区|