目前為止，功能應該算是大體完備

        我的思路是：

        首先將程式碼過一遍，進行區域性插樁，比如if else等分支插{print 當前行}，將所有的當前行按序構造成一個數組

         迴圈體思想也是類似，插計數器，用陣列按序記載所有迴圈次數

        接下來掃描程式碼，提取出所有函式的起始位置和結束位置

        現在開始正式的遍歷，以main函式為入口，逐層呼叫，每個函式裡逐行訪問，首先進行if-else語句和迴圈語句的判斷，

        如果if不執行就跳過直到分支結束，迴圈體就是設定物件訪問應該乘以的倍數

        然後正式開始物件malloc、free以及訪問的判斷，malloc時要設定物件序號（主鍵）、名字、malloc語句的序號

        malloc語句在的函式（不變）、namespace（會隨著return和傳參變化）

        一旦malloc就加入當前物件列表curobjectlist，一旦free掉就加入free列表freelist

        所有判斷物件訪問的條件都是物件在當前物件列表curobjectlist裡且名稱空間namespace和目前所在函式體一樣

        前面說了這個namespace是會變的嘛，因為你return到上層函式或者傳參到下層函式，還是指向同一塊記憶體

        但是指標名字可能會變，如果沒變就只需要改變此物件的namespace即可

        變了就新建一個物件，序號和之前的相同，名字和namespace變化

        當前我還考慮了讓另一個指標指向物件的情況，思路相似，新建一個相同編號的物件即可。

        最後用一個sum函式來進行統計總體訪問次數，輸出表格

        訪問順序也得到了，五個一行（序號+名字）

        後期畫時序圖可以畫成折線圖，橫座標為accesslist的順序編號，縱座標為物件編號

        當有一條直線時，說明就是區域性比較熱的，比如上圖的3號e

        漏說了一個問題：設定這個物件表裡funCall的原因是，一個函式可能會被呼叫很多次，比如我函式裡的hash_insert

        同一段malloc程式碼可能會被執行好幾次，分配幾個並不相同的記憶體（物件），而且被訪問次數可能有的多有的少

        為了插樁分配時方便，我就設定了這個屬性，大意就是第幾次進入這個函式執行malloc程式碼。

        還需要考慮的問題：

        1.迴圈次數為0的情況（暫未做）

            我想可以試著像if那種樁一樣，插一句curline，如果不匹配就直接迴圈次數設為0

        2.迴圈中的break和continue情況（暫未做）

            break的情況稍微簡單一點，遇到break執行就將迴圈次數設為0，知道結束了再重新設為1

            continue時，首先得知道continue執行了n次（一般是在if語句塊裡），然後continue後面語句就是repeat_cnt-n次了

            這個比較麻煩的是，如果迴圈體裡有多個continue和break，會複雜些

            還有考慮掉了一個switch結構，而且這個裡面的break還需和迴圈裡的break區分開

        3.後一步插樁時（已做）

            因為一個子函式裡的程式碼可能會執行很多次，每一次同名物件的訪問次數可能不一樣

            後續的分配nvm和DRAM可能會有所不同，所以要在物件類裡記錄下來執行此函式的次數，這樣好區分

            同樣，為了後續分配工作不重新識別一次，在物件類裡繼續下malloc的地點（即行數）比較方便

        4.物件大小還沒有提取，因為C中是用的sizeof，在Java中不太容易互動。分配需要根據物件大小嗎？

            目前想到的解決方法就是類似於if-else和迴圈體，用一個數組記錄下所有物件大小

            目前已經解決，聽師兄的意思分配策略方面不考慮物件大小，只考慮訪問次數

        5.區域性熱的情況：是應該分階段計算訪問頻度，還是認為當迴圈出現時是最可能出現區域性熱的呢？

            是不是隻考慮一開始存放在NVM當中比較冷的資料區域性變熱呢？

            從NVM遷移到DRAM是個置換過程，相當於先選中兩個置換物件，然後分別插樁

           malloc (nvm_malloc)  memcpy free   這幾個過程

        6.呼叫庫函式，不知道底層對他的訪問，統計起來比較麻煩，不需要考慮

        7.後期自己改程式碼時

            總共malloc記憶體佔多少合適，每個malloc是不是太小沒意義（？之前張博提到）

            物件多少個合適（必須要把DRAM裝滿吧，不然沒有意義）

            DRAM和NVM的配比

            【師兄曾說：和純DRAM對比沒有意義，我們要認為DRAM是有限的，這樣分配和遷移才有意義】

            【可以認為是DRAM放不下，也可以認為是為DRAM節省了空間，讓出這部分空間去跑別的資料】

       8.程式碼的普遍性問題

            我目前是針對字典（手動benchmark做的），只跑一個會不會太少了，別人覺得沒代表性

            跑多了我又怕別的訪存特徵不明顯

       9.HME