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

            隨筆分類

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 303681
            • 排名 - 84

            最新評論

            閱讀排行榜

            最近寫新項目,希望能從內存管理、指針引用的問題上前進一小步,于是在網(wǎng)上爬出云風以前寫的一個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庫的,約摸著底下也就是初始化一些數(shù)據(jù)結構,分配一些初始內存等等。不過至于做了什么,以后再談。
            gc_exit,一看就知道是在程序退出時析構gc庫的,多半是釋放內存。如果實現(xiàn)不是很復雜的話,不調用這個函數(shù)也不會怎樣。
            gc_collect,一定是收集垃圾的了,不過現(xiàn)在就深入這個函數(shù)的話,一定是本末倒置。因為還不知道內存在哪里分配,就去看內存收集顯然是不對的。
            gc_malloc,可以肯定,這就是gc庫的內存分配接口了。好吧,先看看這個函數(shù),我都有點迫不及待了。

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

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

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

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

            這個gc看起來是讓你顯式地維護一個圖,然后手動對一定不能收集的節(jié)點進行標記,然后自己collect。算是【理論上】實現(xiàn)了那個功能。  回復  更多評論
              
            # 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無啥區(qū)別  回復  更多評論
              
            # re: 垃圾收集的那點事(A) 2008-09-10 22:45 陳梓瀚(vczh)
            還是有的,譬如new失敗的時候后臺可以中斷然后collect然后再幫你new。  回復  更多評論
              
            # re: 垃圾收集的那點事(A) 2008-09-11 15:49 空明流轉
            說實話我真覺得不比shared_ptr好多少,RAII才是C++一類貨的王道。  回復  更多評論
              
            久久电影网| 日韩亚洲欧美久久久www综合网| 久久婷婷久久一区二区三区| 18岁日韩内射颜射午夜久久成人 | 无码任你躁久久久久久| 色青青草原桃花久久综合| 人妻精品久久久久中文字幕69| 九九99精品久久久久久| 亚洲国产精品成人AV无码久久综合影院 | 日日狠狠久久偷偷色综合96蜜桃| 亚洲欧美日韩中文久久| 伊人久久精品线影院| 久久精品国产久精国产果冻传媒| 99久久精品国产一区二区蜜芽| 久久人人爽人人人人爽AV| 日本福利片国产午夜久久| 狠狠精品久久久无码中文字幕| 亚洲伊人久久大香线蕉苏妲己| 久久香蕉超碰97国产精品| 久久精品国产男包| 久久强奷乱码老熟女网站| 久久精品中文騷妇女内射| 久久久久久久久久久久久久| 人妻丰满?V无码久久不卡| 久久精品亚洲福利| 国产精品久久久久乳精品爆 | 国产精品欧美久久久久无广告| 久久精品成人欧美大片| 亚洲日本久久久午夜精品| 麻豆久久| 久久精品国产99久久久古代| 久久精品视频一| 欧美日韩精品久久久免费观看| 欧美精品福利视频一区二区三区久久久精品 | 久久久久亚洲精品无码蜜桃| 波多野结衣久久一区二区| 欧美与黑人午夜性猛交久久久| 久久婷婷色综合一区二区| 久久强奷乱码老熟女网站| 四虎国产精品成人免费久久| 亚洲欧美日韩久久精品|