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

            博客搬家了哦,請(qǐng)移步
            叫我abc

            常用鏈接

            留言簿(12)

            隨筆分類

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 303611
            • 排名 - 84

            最新評(píng)論

            閱讀排行榜

            stack_pack將堆棧中的內(nèi)存和所分配的函數(shù)之間建立依賴關(guān)系之后,就到了對(duì) E.pool中所有管理的內(nèi)存進(jìn)行標(biāo)記的時(shí)候了。

             1static void
             2gc_mark(int root)
             3{
             4    if (E.pool[root].mark <  E.mark+1{
             5        struct link *children=E.pool[root].u.n.children;
             6        E.pool[root].mark=E.mark+1;
             7        if (children) {
             8            int i;
             9
            10                for (i=children->number-1;i>=0;i--{
            11                    gc_mark(children->children[i]);
            12                }

            13        }

            14    }

            15}
            由于暫時(shí)還不想考慮weak table的內(nèi)容,我暫時(shí)將這一部分的代碼去掉。
            來看看是如何對(duì)內(nèi)存隊(duì)列進(jìn)行標(biāo)記的。首先,形參root是依賴關(guān)系的父節(jié)點(diǎn),是 E.pool數(shù)組中的索引。在gc_collect中 root = 0,表示從全局根節(jié)點(diǎn)開始,更準(zhǔn)確的說從main函數(shù)對(duì)象開始,遍歷整個(gè)依賴關(guān)系構(gòu)成的樹,對(duì)每一個(gè)節(jié)點(diǎn)進(jìn)行標(biāo)記。
            第4行,是對(duì)節(jié)點(diǎn)是否已經(jīng)被標(biāo)記的判斷。第6行對(duì)該節(jié)點(diǎn)進(jìn)行標(biāo)記。第10、11行則對(duì)該節(jié)點(diǎn)所引用的子節(jié)點(diǎn)重復(fù)這一標(biāo)記過程。
            整個(gè)依賴關(guān)系是樹狀的,利用先序遍歷標(biāo)記所有還被引用的內(nèi)存節(jié)點(diǎn)。這就是gc_mark所作的工作。

            最后,是對(duì)所有沒有標(biāo)記過的內(nèi)存進(jìn)行回收。
             1    for (i=0;i<E.size;i++{
             2        if (E.pool[i].mark < E.mark) {
             3            if (E.pool[i].mark >= 0{
             4                void *p=E.pool[i].u.n.mem;
             5                if (E.pool[i].u.n.finalizer && E.pool[i].u.c.weak!=WEAK_CONTAINER) {
             6                    E.pool[i].u.n.finalizer(p);
             7                }

             8                if ((intptr_t)p != FREED_POINTER) {
             9                    my_free(p);
            10                    map_erase(i);
            11                }

            12                node_free(i);
            13            }

            14        }

            15        else if (E.pool[i].mark == E.mark) {
            16            void *p=E.pool[i].u.n.mem;
            17            if (E.pool[i].u.n.finalizer && E.pool[i].u.c.weak!=WEAK_CONTAINER) {
            18                E.pool[i].u.n.finalizer(p);
            19                E.pool[i].u.n.finalizer=0;
            20            }

            21            my_free(p);
            22            map_erase(i);
            23            E.pool[i].u.c.mem=FREED_POINTER;
            24        }

            25    }
            用for循環(huán)遍歷 E.pool,所有分配的內(nèi)存,因?yàn)楸粯?biāo)記的內(nèi)存的值是 E.mark + 1,所以只要 E.pool[i].mark <= E.mark的,都算是垃圾內(nèi)存了,因此for循環(huán)里面的兩個(gè) if 和 else if在垃圾內(nèi)存的角度上并沒有差別,都是被回收的內(nèi)容,但是這兩個(gè)代碼塊多少還是有差異的,因此稍微想了一下。
            首先,從之前做標(biāo)記的代碼看,沒有被標(biāo)記過的內(nèi)存應(yīng)該是小于 E.mark的,因此if代碼塊是理解上的正常流程。而else if 部分,檢測(cè)內(nèi)存的標(biāo)記等于 E.mark,這個(gè)怎么看都是沒有可能的,因?yàn)闃?biāo)記值是 E.mark+1,而E.mark以+2遞增。這有可能是其他一些我還沒看過的代碼,對(duì)節(jié)點(diǎn)進(jìn)行了標(biāo)記也說不定,畢竟還有一個(gè)weak_table沒有接觸呢。
            此外還有一個(gè)細(xì)節(jié),else if部分,沒有調(diào)用node_free(i),釋放了內(nèi)存,但是節(jié)點(diǎn)保留著,這讓我更確認(rèn)這是一塊還沒有開辟的代碼區(qū)域造成的,不過,這還是等以后看到相關(guān)內(nèi)容的時(shí)候,再來考證這里的內(nèi)容吧。

            最后,來看看gc_link中解除依賴關(guān)系的代碼,現(xiàn)在已經(jīng)對(duì)整個(gè)gc庫(kù)有了整體的認(rèn)識(shí),這部分代碼也就不在話下了
            1    if (prev) {
            2        int prev_id=map_id(prev);
            3        stack_push(prev_id);
            4        node_add(parent_id,prev_id | UNSET_MASK);
            5    }
            第3行,將被解除關(guān)系的內(nèi)存id壓入堆棧,看起來目的是讓這塊內(nèi)存再稍微活長(zhǎng)久一點(diǎn),至少要活到離開當(dāng)前函數(shù)后。
            然后第4行,解除了之前主動(dòng)添加的依賴關(guān)系,在cache_flush的時(shí)候,將會(huì)從children數(shù)組中刪除prev_id。
            posted on 2008-09-22 21:55 LOGOS 閱讀(4824) 評(píng)論(4)  編輯 收藏 引用 所屬分類: 垃圾收集

            FeedBack:
            # re: 垃圾收集的那點(diǎn)事(J) 2008-09-22 22:44 來支持
            都還沒去下過云風(fēng)原始的代碼,到是從博主這里看出一點(diǎn)頭緒來,這么感覺出有點(diǎn)LUA的味道啊。對(duì)lua研究不深,隨便說說,呵呵。  回復(fù)  更多評(píng)論
              
            # re: 垃圾收集的那點(diǎn)事(J) 2008-09-23 10:32 cexer
            哪里有下載的源碼  回復(fù)  更多評(píng)論
              
            # re: 垃圾收集的那點(diǎn)事(J) 2008-09-23 10:57 LOGOS
            # re: 垃圾收集的那點(diǎn)事(J) 2008-09-23 17:40 cexer
            @LOGOS
            多謝了,我也研究研究。  回復(fù)  更多評(píng)論
              
            久久99精品国产自在现线小黄鸭| 国产69精品久久久久9999APGF| 中文字幕无码久久精品青草| 国产伊人久久| 久久国产乱子伦精品免费午夜| 久久99国产精品久久| 热99re久久国超精品首页| 久久久久久免费一区二区三区| 韩国三级大全久久网站| 久久国产成人精品麻豆| 久久91精品国产91久久麻豆| 9191精品国产免费久久| 久久久WWW成人免费精品| 久久人人超碰精品CAOPOREN| 久久人人爽人人爽人人片AV高清 | 久久AAAA片一区二区| 久久综合狠狠综合久久激情 | 青青草原综合久久大伊人精品| 国产—久久香蕉国产线看观看| 国产成人精品久久| 一极黄色视频久久网站| 精品蜜臀久久久久99网站| 91超碰碰碰碰久久久久久综合 | 国产午夜精品久久久久九九| 国产精品伦理久久久久久| 亚洲国产成人精品91久久久| 久久强奷乱码老熟女网站| 久久国产精品一国产精品金尊 | 久久久久久国产精品免费免费| 久久综合亚洲色HEZYO社区| 久久精品人人槡人妻人人玩AV | 亚洲精品无码久久久久sm| 久久精品国产免费一区| 久久亚洲高清综合| 国内精品人妻无码久久久影院 | 亚洲成av人片不卡无码久久| 国产亚洲精品自在久久| 色诱久久av| 成人a毛片久久免费播放| 亚洲精品乱码久久久久66| 久久中文精品无码中文字幕|