• <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>
            posts - 18,  comments - 104,  trackbacks - 0
            上篇說到垃圾回收器的一些基本原理。這次說說這個垃圾回收器最終效果啥呀。有著明確的需求,說起來會更清晰,更明確。

            看代碼吧。

            struct A
            {
                int i,j,k;

                Begin_Member_Pointer(A)
                End_Member_Pointer

                
            };


            struct B
            {
                pointer<A> data0;

                B()
                {
                    data0 = gc.malloc<A>();
                }

                Begin_Member_Pointer(B)
                Member(data0);
                End_Member_Pointer

            };

            pointer<B> test()
            {
                pointer<B> pB = gc.malloc<B>();
                //做一些事情
                return pB;
            }

            void main()
            {
                pointer<B> pB = test();
                //做一些事情
                gc.collect();
                gc.compress();

            }

            看看上面的一段代碼,基本演示了怎么用這個垃圾回收器。

            1.  gc.malloc< >(  ) 為對象分配空間,并調用構造函數。gc.malloc有多個參數的模板函數,構造函數的參數直接放里面就可以。
            2.  能被垃圾回收器回收的對象,必須定義一個以Begin_Member_Pointer(TypeName) 開始,以End_Member_Pointer結束,中間包含所有pointer類型成員變量的列表(順序無關)。
            3.  在任意時候調用gc.collect(  )來回收所有無用內存,并會對所有被回收的對象調用析構函數。
            4.  在回收后可以選擇調用gc.compress(  )來緊縮內存。

            當然現在如果有朋友讀過源碼,會發現和上面所有有些不一致,不過上面是最終的效果。

            這里就對指針的使用有了一些限制,

            1. 所有受垃圾回收器控制的內存的指針是以 pointer<type> 的形式存在,而且是強制的。pointer類型不能轉化成普通指針,而且gc.malloc函數返回的也是pointer類型的指針,這個是必須的,因為要實現內存緊縮,所有的指針必須受控)。
            2. 所有的類型定義里面必須包含對成員指針的一個描述,見上面第2條。否則想上面在B的構造函數中申請出來的A對象就無法被釋放了。

            這些對成員的描述就是上面圖中粉紅色圓圈的指針了,如果沒有這些定義,有些內存塊的可達性判斷就可能失效。

            這里我做了一些簡化,暫時不考慮多核多線程,所以寄存器可以不考慮,這大幅降低了編碼的復雜度,使得代碼更容易理解。

            先看看所有的數據結構吧:

            //掃描成員指針的函數指針
            typedef void (*marker) (const void* ptr, void(*func)(const pointer_base&));

            //根集
            std::list<pointer_base *> gc_root_set;

            //內存塊節點
            struct node
            {
                
            void* mem;        //內存指針(普通指針)
                unsigned int size;    //內存大小
                unsigned int mark;    //當前的標志
                marker func;        //掃描函數指針
                destructor finalizer;    //析構函數指針
            }
            ;

            //內存塊集
            std::map<const void *, node> gc_holder;
            //標志
            unsigned int gc_marker = 0;
            //標志當前指針是否屬于根集
            bool gc_is_root_set_locked = false;
            //所有指針集(用于緊縮)
            std::multimap<const void*const pointer_base*> gc_pointer_set;
            //緊縮時用的緩沖
            std::map<const void*const void*> gc_swap_buffer;

            上面就是全部的數據結構,需要說明的是:
            1。 那個marker是一個函數指針,它的第二個參數也是個函數指針。
            2。 了解C++的朋友可能會說,析構函數不能對其取地址。當然這里用了一個小小的技巧---對析構函數進行了包裝。

            template <class _T>
            void gc_destructor(_T* p)
            {
                p
            ->_T::~_T();
            }
            ;

            typedef 
            void (*destructor) (void*);

            struct node
            {
                
            void* mem;
                unsigned 
            int size;
                unsigned 
            int mark;
                marker func;
                
            //注意類型
                destructor finalizer;
            }
            ;

            node n;
            //這是關鍵
            n.finalizer = (destructor)&gc_destructor<_T>;

             

            3。 注意gc_mark不是一個bool變量,它會隨著每次分配而++,在collect之前,會用++mark來標記所有可達內存塊,即node.mark = gc_mark; 于是,所有mark值和gc_mark不等的內存塊就需要被回收啦。

            從下篇開始就逐個介紹各個函數了,最后再用宏或模板做出來一些語法糖,把見不得人的東西都包起來,就大功告成了。

            posted on 2010-02-10 19:09 尹東斐 閱讀(2604) 評論(10)  編輯 收藏 引用

            FeedBack:
            # re: C++下垃圾回收器的實現(二)--析構函數的地址?
            2010-02-10 19:54 | jimmy
            果然大牛啊!!  回復  更多評論
              
            # re: C++下垃圾回收器的實現(二)--析構函數的地址?
            2010-02-12 12:23 | Benjamin
            如果能考慮一下異常,會完整些  回復  更多評論
              
            # re: C++下垃圾回收器的實現(二)--析構函數的地址?
            2010-02-13 12:00 | yindf
            @Benjamin

            完成了會考慮的,謝謝支持。  回復  更多評論
              
            # re: C++下垃圾回收器的實現(二)--析構函數的地址?
            2010-02-18 12:04 | 路過
            失敗的垃圾設計,買本《垃圾收集》來看看好不?  回復  更多評論
              
            # re: C++下垃圾回收器的實現(二)--析構函數的地址?
            2010-02-18 20:01 | yindf
            @路過

            呵呵~~你看過的話在C++下實現一個吧,我求你了。  回復  更多評論
              
            # re: C++下垃圾回收器的實現(二)--析構函數的地址?
            2010-02-18 21:53 | 路過
            《Garbage Collection》Jones, Richard/ Lins, Rafael著,
            強烈建議仔細讀讀這本書,去看看HP CPPGC源碼。概念不清,常識性錯誤。
            唉。。。  回復  更多評論
              
            # re: C++下垃圾回收器的實現(二)--析構函數的地址?
            2010-02-19 02:25 | yindf
            @路過

            HP gc看過啦,我在上篇提到過,HP gc有它的缺點。
            C++不能完全控制指針,所以HP gc說過,它是“保守的”垃圾回收。

            而我這個,就是精確的。  回復  更多評論
              
            # re: C++下垃圾回收器的實現(二)--析構函數的地址?
            2010-02-20 00:15 | 路過
            精確的?!Are you kidding?!  回復  更多評論
              
            # re: C++下垃圾回收器的實現(二)--析構函數的地址?
            2010-02-20 22:41 | yindf
            @路過

            呵呵,只要是用gc malloc 分配出來的,都可以保證在不用的時候,通過collect收集。 HP gc不行。  回復  更多評論
              
            # re: C++下垃圾回收器的實現(二)--析構函數的地址?
            2010-04-06 09:30 | 不知所謂
            樓主你去看看樓上說的那本書好不咯?你這個所謂gc簡直就是幼稚得搞笑  回復  更多評論
              
            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            常用鏈接

            留言簿(4)

            隨筆檔案

            文章分類

            文章檔案

            相冊

            好友博客

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            91久久精一区二区三区大全| 欧美精品丝袜久久久中文字幕| 精品久久久无码21p发布| 2021久久精品免费观看| 久久天天躁狠狠躁夜夜96流白浆| 国内精品久久人妻互换| 久久久精品日本一区二区三区| 欧美激情一区二区久久久| 99久久成人国产精品免费| 久久精品免费大片国产大片| 色偷偷88888欧美精品久久久| Xx性欧美肥妇精品久久久久久| 色青青草原桃花久久综合| 人妻无码中文久久久久专区| 精品久久久久久无码人妻热 | 久久婷婷五月综合色奶水99啪| 热久久这里只有精品| 精品久久久久久久国产潘金莲| 久久精品国产亚洲AV嫖农村妇女| 亚洲国产精品综合久久网络| 伊人热人久久中文字幕| 久久人人爽人人爽人人AV | 久久青青草原亚洲av无码app | 久久久一本精品99久久精品88| 久久久久久av无码免费看大片| 99re这里只有精品热久久| 久久无码高潮喷水| 人妻无码久久精品| 精品久久香蕉国产线看观看亚洲| 精品久久久无码21p发布| 一级a性色生活片久久无少妇一级婬片免费放 | 久久亚洲2019中文字幕| 亚洲精品国产成人99久久| 久久精品亚洲中文字幕无码麻豆| 亚洲综合熟女久久久30p| 7777精品伊人久久久大香线蕉 | 青草影院天堂男人久久| 91精品国产色综合久久| 精品免费tv久久久久久久| 亚洲伊人久久大香线蕉苏妲己 | 7777精品久久久大香线蕉 |