• <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)論
              
            亚洲精品tv久久久久| 久久久久免费看成人影片| 久久99久久99精品免视看动漫| 久久精品国产福利国产秒| 亚洲AV无一区二区三区久久| 欧美国产精品久久高清| A级毛片无码久久精品免费| 国产午夜免费高清久久影院| 亚洲va中文字幕无码久久不卡| 国产香蕉久久精品综合网| 久久夜色精品国产www| 国产99久久久国产精免费| 国产激情久久久久影院小草| 久久综合九色综合精品| 99久久精品免费看国产免费| 99久久久久| 久久嫩草影院免费看夜色| 久久久WWW成人| 久久综合鬼色88久久精品综合自在自线噜噜 | 久久久久久综合一区中文字幕| 三上悠亚久久精品| 久久99精品久久久久婷婷| 国产亚洲婷婷香蕉久久精品| 日本福利片国产午夜久久| 久久久久国产精品嫩草影院| 久久夜色精品国产噜噜亚洲a| 久久九九久精品国产免费直播| 日韩人妻无码一区二区三区久久| 久久99精品久久久久久动态图| 中文字幕亚洲综合久久2| 热RE99久久精品国产66热| 99久久国产宗和精品1上映| 国内精品久久久久| 亚洲另类欧美综合久久图片区| 狠狠综合久久综合88亚洲| 色综合久久88色综合天天| 天天影视色香欲综合久久| 成人免费网站久久久| 婷婷久久综合九色综合九七| 97久久久久人妻精品专区| 要久久爱在线免费观看|