摘要 摘要 本文面向嵌入式實時應用需求，在深入研究嵌入式實時系統(tǒng)和內存管理技術， 國內外的研究現(xiàn)狀和研究方向，系統(tǒng)的內存模式和內存管理的特點的基礎上，提 出了本文的研究目標和研究內容，提出并實現(xiàn)了一系列有助于提高系統(tǒng)安全性和 可靠性的內存管理技術解決方法，包括：動態(tài)內存分配，內存保護等，在靜態(tài)配置 u b 的基礎上引入了“交換塊( sb l o c k ) ”的概念，并對其實現(xiàn)技術展開較為深入 的研究。 文中提出要解決的問題并給出涉及到的技術理論，進行系統(tǒng)的需求分析給出了 系統(tǒng)中內存數據的組織方式，描述了系統(tǒng)實現(xiàn)，并進行了測試分析。為保證嵌入 式實時系統(tǒng)數據存儲的安全性和可靠性，對內存管理技術的研究具有重要意義。 關鍵詞：嵌入式系統(tǒng)內存管理叩 a b s t r a c ：f a b s t r a c t w i t ht h er e q u i r e m e n to fr e a l - t i m ee m b e d d e da p p l i c a t i o n , as y s t e m a t i cs u r v e yo f r e s e a r c hi nt h ed o m a i no fe m b e d d e dr e a l t i m ea n dm e m o r ym a n a g e m e n ti s g i v e n ， i n c l u d i n gt h ec o n c e p to fr e a l t i m ee m b e d d e ds y s t e m ，t h er e s e a r c hs t a t u sa n dt e n d e n c yf r e a l - t i m ee m b e d d e d s y s t e m ，t h e c h a r a c t e r i s t i co fm e m o r ym o d e la n d m e m o r y m a n a g e m e n ti nr e a i - t i m ee m b e d d e ds y s t e m t h e nt h es t u d yo b j e c t i v e sa n dc o t e n t so f t h et h e s i sa r ep r e s e n t e d as e r i e so f m e m o r ym a m a g e m e n tt e c h n o l o g yt oi m p r o v es a f e t y a n dr e l i a b i l i t yf o re m b e d d e ds y s t e ma r ep r o p o s e da n di m p l e m e n t e di nt h et h e s i s i n c l u d i n gm e m o r yr e d u n d a n c ya l l o c a t i o n ，m e m o r yr e d l l l l d a n c ye n c o d i n ga n dm e m r y p r o t e c t i o n t h e nt h ek e yt e c h n o l o g yo f t h e s ei sr e s e a r c h e da n di m p l e m e n t e d h e r ep u t sf o r w a r dt h ep r o b l e m ，c a r r i e st h r o u g hr e q u i r e m e n ta n a l y s i sa n db u i l d u p d a t ai nt h em a i nm e m o r y , d e s c r i b e st h ed e s i g no ft h ea r c h i t e c t u r e ，r e c o r d st h et e s t i n g a n dd e b u g g i n gd a t aa n dp r o v i n gt h er u n n i n ge n v i r o n m e n t i no r d e rt oi m p r o v et h es a f e t y a n dr e l i a b i l i t yo fd a t as t o r a g ei nr e a l - t i m ee m b e d d e ds y s t e m , r e s e a r c ho nm e m o r y m a n a g e m e n tf o re m b e d d e ds y s t e mi sp a r t i c u l a r l ys i g r t f i c a n t k e y w o r d ： e m b e d d e d 聆a b f i m e m e m o r ym a n a g e m e n t u b 創(chuàng)新性聲明 本人聲明所呈交的論文是我個人在導師指導下進行的研究工作及取得的研 究成果。盡我所知，除了文中特別加以標注和致謝中所羅列的內容以外，論文中 不包含其他人已經發(fā)表或撰寫過的研究成果；也不包含為獲得西安電予科技大學 或其它教育機構的學位或證書而使用過的材料。與我一同工作的同志對本研究所 做的任何貢獻均已在文中作了明確的說明并表示了謝意。 申請學位論文與資料若有不實之處，本人承擔一切相關責任。 本人簽名：蘧盤霪 日期：五翌生：! 關于論文使用授權的說明 本人完全了解西安電子科技大學有關保留和使用學位論文的規(guī)定，即：研究 生在校攻讀學位期間論文工作的知識產權單位屬西安電子科技大學。本人保證畢 業(yè)離校后，發(fā)表論文或使用論文工作成果時署名單位仍然為西安電子科技大學。 學校有權保留送交論文的復印件，允許查閱和借閱論文；學?？梢怨颊撐牡娜?部或部分內容，可以允許采用影印、縮印或其它復制手段保存論文。( 保密的論 文在解密后遵守此規(guī)定) 本學位論文屬于保密，在年解密后適用本授權書。 本人簽名：縊童篷 導師簽名：牛 日期： 第一章緒論 第一章緒論 本章首先簡妻介紹了內存管理模塊在3 0 統(tǒng)一平臺支撐層的位置，傳統(tǒng)內存管 理方法的的應用、現(xiàn)狀及前景，由此引出在內存管理中存在的問題，指出了內存 管理的重要性。最后給出了本文的主要工作以及內容安排。 內存管理模塊在o s s 系統(tǒng)中的位置如圖1 i 所示： 圖1 1 內存管理在0 s s 中的位置 內存管理完成兩個主要功能。一是內存分配管理，二是內存保護。對于長期運 行、實時性要求高的系統(tǒng)，必須自己對內存進行管理。 v x w o r k s 自身提供的內存管理函數采用f i r s t - m 算法。該算法在搜索可用的內 存塊時，從空閑隊列頭開始進行搜索，當找到第一個空間足夠的空閑內存塊時， 即將該空閑塊分配給其使用，剩余部分重新加入空閑隊列。這種算法不適用于我 們的系統(tǒng)。采用f i r s t - f i t 算法，一是內存分配的實時性得不到保證，具體的搜索時 問和已分配的內存塊個數成o ( n ) 的關系，二是會產生內存碎片。 現(xiàn)存的內存管理模塊具有設計簡單、實時性強、效率高等優(yōu)點，但使用靜態(tài)配 置u b 的方法很難避免配置上不合理所帶來問題( u b 缺失或浪費) 。內存管理的 輔助功能( 向上申請及系統(tǒng)對內存擴展) 在一定程度上緩解了u b 配置問題，但又會 帶其它一些問題。比如向上申請會引起實時性變弱；系統(tǒng)堆內存擴展將v x w o r k s 本身內存管理的碎片問題暴露出來。 為解決上述問題，在保證現(xiàn)有u b 管理優(yōu)點的基礎上，并考慮盡量合理有效的 利用內存資源，將“交換塊( sb l o c k ) ”的概念引入到u b 管理中來。引入“交換 塊”的概念后，實際上是在目前u b 管理的基礎上增加了一個層次，向內存池申請 3 g 統(tǒng)一平臺的內存管理研究 u b 時，先要獲取一個可用的交換塊，進而獲取己可用u b 。交換塊可以被多個內 存池交替使用，根據u b 尺寸的大小，一個交換塊被分解成若干u b 。交換塊l i b 動態(tài)管理機制可以解決u b 池間內存不能共享等問題。 對于u b 保護，考慮到原來設計方案在打開l i b 保護功能時會浪費很多內存， 甚至導致系統(tǒng)由于內存不夠而不能正常啟動，在設計時考慮支持動態(tài)打開u b 保護 功能，并支持對個別內存池進行保護，當然在內存資源夠用時可以對全部u b 池進 行保護。 本模塊引用v o s 標準模塊，提供的三套接口作為標準模塊為上層應用模塊和 支撐層內部使用，其中，一套只給支撐層內部通信使用。 第二章內存管理模塊 第二章內存管理模塊 2 1 概述 內存管理模塊主要由內存分配和內存保護兩個相互獨立的子模塊組成。內存分 配子模塊由三個部分組成。按用途分，可以分為如下三種： 1 支撐內部使用，比如，進程間通信( 消息構造時由通信模塊為消息分配內存 空間，消息處理完畢，由調度模塊釋放占用的內存空間) 。 2 上層應用使用內存。 3 全局內存分配。( 只在初始化的時候使用，一般的應用場合不使用。) 內存分配基于隊列操作( 由v o s 模塊提供) 。 內存保護包括三個部分，一個是u b 的保護，一個是進程棧和私有數據區(qū)的保 護，全局變量的保護需要應用配合完成，保護流程同進程棧和私有數據區(qū)相同。 內存管理模塊功能組成框圖如圖2 1 所示： 圖2 1 內存管理框架 2 2 核心數據區(qū)初始化 支撐內部的核心數據統(tǒng)一排布，所謂的核心數據，是指支撐內部使用的全局變 4 3 g 統(tǒng)一平臺的內存管理研究 量。所有的核心數據都放在一個大的數據結構里面，先定義tc o r e d a t a + p t c o r e d a t a 。對于大塊數據，在t - c o r e d a t a 內部加一結構指針，然后在內存初始 化的時候動態(tài)分配。這樣，通過p t c o r e d a t a ，就可以定位所有的核心數據。 2 3 1 概述 2 3 內存分配子模塊 內存分配子模塊主要實現(xiàn)對堆的動態(tài)申請和釋放。v x w o r k s 也提供堆的動態(tài)管 理，但其不適用于我們的系統(tǒng)。內存分配子模塊只給上層應用提供兩類接口，一 個用于申請內存，一個用于釋放內存。 內存分配子模塊的設計目標是保證動態(tài)申請內存和釋放內存的實時性，將內存 碎片限制在可控的范圍之內。內存分配子模塊基于內存池集機制，對不同的應用 場合，使用不同的內存池集。3 g 統(tǒng)一平臺使用兩套完全獨立的內存池集，即內部 內存池集和應用內存池集。內部內存池集為支撐內部提供內存申請支持，這是支 撐內部自己使用的內存池集，不對外開放。應用內存池集為上層應用提供高效的 動態(tài)內存申請機制。 每個內存池集被分成若干個內存池，每個內存池包含相等數目的內存塊和內存 頭，同一內存池中的內存塊尺寸相同。內存池由循環(huán)隊列進行管理，以達到實時 性。內存塊的尺寸的最小單位為m e mu bs p a n ( 目前定為6 4 ) ，其余內存塊的 大小為m e m u bs p a n 日整數倍，其大小沒有上限。內存塊個數可以根據應用需 要在文件中自行配置。 每個內存池由一個循環(huán)隊列來管理。引入循環(huán)隊列可以加快內存塊的申請和釋 放。除去信號量等待的情況，每次申請內存塊的時間是一樣的。 上層應用如果需要使用到內存的動態(tài)申請，仍然采用內存池集管理機制。內部 內存池集和應用內存池集完全獨立，互不干擾，這樣做的優(yōu)點是一套內存池集的 耗竭不會影響另一套內存池集的正常工作。這樣，3 g 平臺提供兩套內存池集，一 套只給支撐內部使用，一套給上層應用使用，目前包括協(xié)議棧和信令。 另外，支撐層還提供對m a l l o e 函數的封裝。作一層封裝的目的只是為了加入 統(tǒng)計功能。通過自封裝的函數，支撐層就可以完全掌握應用對內存的使用情況。 此函數只在支撐內部和初始化的時候預分配內存使用。 下圖是隊列、內存頭和內存體之間的關系圖。 第二章內存管理模塊 操作隊列固定內存固定內存 圖2 1 隊列、內存頭和內存塊之間的關系 從圖2 2 中可以看出，內存頭和內存塊的排列關系是有規(guī)律可循的，這種對應 關系在運行過程中不會改變。第一個內存頭永遠被用來控制第一個內存塊，而不 可能去控制別的內存塊。但是內存頭指針在隊列中的位置是會不斷改變的。從隊 列中取出的一個內存頭指針，可以指向任何一個內存頭。 2 3 2 隊列操作 對每個內存池，初始化的時候先創(chuàng)建一塊連續(xù)內存，用以存放內存頭指針。并 用頭、尾兩個索引來分別代表當前可用第一個內存頭和當前可用的最后一個內存 頭。取可用內存時，從內存池控制塊中取得頭索引，而后取得內存頭指針。釋放 內存時，取得尾索引，而后將內存頭指針歸還。 由于u b 的申請和釋放在系統(tǒng)中會頻繁使用，為了提高效率，在申請u b 的時 候，將申請者申請的內存大小增加8 字節(jié)，增加的部分用以存放釋放信息，包括 隊列頭和內存頭指針。當釋放內存時，可以得到指針值，將指針前移8 個字節(jié)， 就可以得到內存頭指針和隊列頭。從而避免了釋放信息的搜索過程。 2 3 3 內存子模塊初始化流程 該初始化流程負責整個內存子模塊的初始化工作，并向其它子模塊提供一個函 數接口m e m _ s y s i n i t 。 傳入參數：無。 內存初始化流程如下： 6 3 g 統(tǒng)一平臺的內存管理研究 r 開始、 l 為核心數據區(qū) 數據結構分配內存空間 上 獲得頁尺寸 上 i初始化內 i存池集控制塊 上 初始化 l內存池集 上 i設置標志位 i 上 r 結束 、 圖2 2 內存子模塊初始化流程 流程描述： 1 、為核心數據區(qū)數據結構分配內存空間，并清零。 2 、獲得頁尺寸大小。 3 、初始化內存池集控制塊，標記所有的內存池集控制塊沒有被使用。 4 、初始化內部內存池集。 5 、初始化用戶內存池集。 6 、標記初始化已經完成。 其中，第4 、5 步的流程完全相同。 2 3 4 初始化內存池集流程 傳入參數： 第二章內存管理模塊 7 tu b i n f o + p t u b i n f 卜指向內存池集的配置信息。 w o r d 3 2 d w c f 奢t b l l e n 一配置表的長度，其值由如下兩個宏決定。 內部內存池集由宏m e mi n n e r u bp o o ln u m 決定，用戶內存池集的長度 由宏m e mu bp o o ln u m 決定。 概況來講，初始化流程主要完成下面三部分的工作： 根據內存配置表進行內存預分配，內存配置表有兩套。 創(chuàng)建控制隊列，引用v o s 標準模塊的隊列操作。 對內存頭和內存體加頁保護。 下面描述對內部內存池集的初始化過程，應用內存池集的初始化過程與之相 同。 8 3 g 統(tǒng)一平臺的內存管理研究 圖2 4 內存分配子模塊初始化 流程描述： 1 、進行合法性檢查( 按內存池號循環(huán)) ，主要是檢查用戶的數據是否配置正確。 包括，內存塊大小是否為m e mu bs p a n 的倍數，內存池中內存塊大小 是否按序增長。 2 、獲得頁尺寸d w p a g e s i z e ，如果頁保護開關打開，則返回的是4 0 9 6 個字節(jié)， 否則，返回6 4 個字節(jié)。 第二章內存管理模塊 9 3 、創(chuàng)建互斥信號量，一個內存池集有一個互斥信號量。 4 、計算虛擬內存總空間，總空間的計算根據l i b 頭尺寸和u b 塊大小來確定。 同一個內存隊列的 u b頭放在一起，間隔 m e mp r o t e c tp a g ec o u n t 個保護頁。在內存頭之后，排放內存塊。 內存塊之間同樣插入m e mp r o t e c tp a g ec o u n t 個保護頁。 5 、調用v o s 提供的虛擬頁申請函數，保留一段虛擬內存( 已經包括保護頁) ， 這段內存初始狀態(tài)為不可訪問，由p t v i r t u a l m e m o r y ( 臨時變量) 指定。 6 、p t v i r t u a l m e m o r y 加一個頁，為第一個內存池的內存頭前面加虛擬保護頁。 7 、從p t v i r t u a l m e m o r y 處提交內存頭內存，這段內存可以讀寫。 8 、調用v o s 提供的隊列創(chuàng)建接口，創(chuàng)建一個無信號量、不可擴展的隊列，將 隊列句柄存入對應的隊列控制塊。 9 、提交內存塊( 按內存塊號循環(huán)) 。保護的格局見內存池集的保護( 圖) 。 1 0 、如果內存保護開關沒打開，則將該內存塊全部置為0 x 5 a ，以便以后檢測 使用。 l l 、將內存塊指針存入內存頭。 1 2 、將內存頭指針入隊。 保護頁 內存頭i ( 池1 ) 內存頭2 ( 池i ) 內存頭n ( 池1 ) 保護頁 內存塊i ( 池i ) 保護頁 內存塊2 ( 池i ) l 保護頁 內存塊n ( 池i ) 圖2 5 內存池集的保護 1 0 3 g 統(tǒng)一平臺的內存管理研究 圖2 5 只畫了一個內存池的保護格局，其它內存池的保護格局與此完全相同。 2 3 5 申請內存流程 傳入參數： t _ p o o l o r o u p c t r l + p o r p c t l 指定對哪個內存池集進行操作。 w o r d 3 2 d w s i 蠲- _ 一申請u b 大小。 w o r d 3 2 d w l f u s e r e s e n ，e 一是否使用保留內存。 u s er e s e v e rm e m - - 使用 n ou s er e s e v e rm e m 一不使用 w o r d 3 2 d w t l m e o u t 一一超時值( 目前定為5 0 0 m s ) 。 下圖是內存申請的分配流程： 圖2 6 內存申請流程 流程描述： l 、 參數的合法性檢查，尺寸必須介于0 和最大尺寸之間。 2 、根據尺寸從內存池集中尋找合適的內存池。 3 、 進入信號量保護。 第二章內存管理模塊 4 、如果該內存池沒有可用內存，則向更大的內存池申請可用內存。 5 、 從隊列頭中取得內存塊頭指針。 6 、 記錄申請點在源文件中的位置。存申請函數在源文件的位置，包括文 件名和行號。 7 、 統(tǒng)計內存池占用情況，包括內存池中當前占用的內存塊的個數，內存 池中最多占用的內存塊的個數。 8 、返回申請的內存塊。一般來說，分配給應用的內存比實際需要的要多。 返回指針的方式有兩種，一種是將低端地址返回，另外一種是將高端地址 減去實際所需要的內存大小，而后返回。由于內存越界最多的情況是向后 越界引起，因此，采用第二種方法，只要越界，就可以觸發(fā)異常。 9 、 釋放信號量。 2 3 6 釋放內存流程 傳入的參數： 1 - p o o l g r o u p c t r l + p g r p c t l 指定對哪個內存池集進行操作。 b y t e + p u c b u f 一指向待釋放內存塊。 圖2 7 是內存釋放的流程： 1 2 3 g 統(tǒng)一平臺的內存管理研究 圖2 7 內存釋放流程 l 、合法性檢查，指針必須在內存池集的范圍之內。 2 、獲得內存體偏移，根據p u c b u f 獲得其離內存體頭部的偏移位置。( 由p u e b u f 同各內存池控制頭中記錄的內存范圍進行比較，如果落入該內存池范圍， 則認為找到對應的內存池。) 3 、獲得對應的內存頭指針，根據偏移位置得到內存頭指針。 4 、進入信號量保護。 5 、根據使用標識，判別是否重復釋放。 6 、根據內存頭，判別返回指針是否落在內存塊限定的范圍內。 7 、置使用標識位為可以使用，然后將內存頭指針加入隊列。 第二章內存管理模塊 8 、如果沒有內存保護，則將內存塊中相應的內容重置為0 x 5 a 。 9 、記錄跟蹤信息。 1 0 、 釋放信號量保護。 2 3 7 統(tǒng)計功能 統(tǒng)計功能包括如下部分： 1 、支撐占用的內存總量，包括兩套內存池集，所有使用o s sm a l l o e 分配內 存的情況。對于v x w o r k s 內核自身使用的內存空間可以使用內核自身提 供的m e m s h o w 命令來顯示。 2 、u b 的使用情況。包括當前u b 池的使用情況，u b 池最大的使用個數。 2 3 8 可測試性設計 2 3 8 1 測試范圍 測試重點包括下面幾個方面： 初始化 申請內存 釋放內存 另外，由于u b 塊保護在內存分配子模塊中實現(xiàn)，因此，測試設計也考慮了 u b 塊的保護。 2 3 8 2 測試方法 創(chuàng)建兩個進程，假設進程名分別為s e n d e r 和r e c e i v e r ，分屬不同的調度任務， 任務優(yōu)先級不同( 可以測試內存池集的信號量保護是否正確) 。s e n d e r 進程以時間 間隔d w s e n d i n t e r v a l 申請大小為d w m e m s i z e 的內存，并且內存內容全部置為0 x 2 2 ， 而后將內存指針、內存大小發(fā)送給r e c e i v e r 進程。接收進程收到之后，同步延時 d w r e c i n t e r v a l 秒。而后根據收到的消息，對內存內容進行校驗，如果內容不全為 0 x 2 2 ，則證明有問題，此時，應該停止發(fā)消息( 方法是將d w s e n d l m e r v a l 和 d w r e c l m e r v a l 置為o x 蝴) 。如果全為0 x 2 2 ，則將內存釋放。d w s e n d i n t e r v a l 、 d w m e m s i z e 和d w r e c i n t e r v a l 作為全局變量，可以在s h e l l 中直接修改。 內存分配模塊的測試模型如下所求： 1 4 任f 嬲差逆睫 務么 a r 菌 3 g 統(tǒng)一平臺的內存管理研究 將內存全部置 為0 x 2 2 二級調度 內存分配測試模型 對于u b 保護的測試，只要在置內存值為0 x 2 2 的時候，將寫操作的長度超出 申請的內存大小，從而觸發(fā)異常處理流程。 2 4 內存保護子模塊 內存保護包括兩個部分，u b 的保護和頁表切換保護。 內存保護子模塊的主要作用是在于河題定位。內存保護引入虛擬內存機制，通 過頁表屬性的設置來決定內存的訪問權限。引入內存保護的會引起程序運行效率 下降，特別是在頁表頻繁切換的時候，因此，內存保護實現(xiàn)的完備程度受運行效 率的限制。 2 4 1 概述 對所有靜態(tài)配置的u b ，按插入虛擬頁的方式進行保護。u b 在內存中的排布 如圖內在迪塞堡塑揸旦所示。加入對u b 的保護之后，對p p c 體系，如果頁數增 加過多，理論上有可能會降低效率。對于x 8 6 體系，由于每次查找頁表所需要的 一震 任務b 第二章內存管理模塊 步驟相同，因此，不可能降低效率。另外，因為頁的最小尺寸目前定為4 0 9 6 字節(jié)， 因此，加入u b 保護，對于不是頁整數位的內存塊，會浪費內存。 在3 g 統(tǒng)一平臺中，為了實現(xiàn)盡可能完全的保護，內存被劃分成兩個空間，一 是系統(tǒng)空間，一是進程空間。這兩個空間的唯一區(qū)別就在于對內存的訪問權限上， 而不在指令權限上。每個空間由一套頁表來維護。o s s 初始化完成后，對于內存 的訪問只需要一套頁表完成。 系統(tǒng)空間擁有對內存資源最大的控制權，除了對代碼段不可寫之外，對進程棧 和私有數據區(qū)不可寫之外，對所有的內存區(qū)都可讀寫。進程空間只可以對本進程 的棧和私有數據區(qū)可讀寫，對其它進程的棧和私有數據區(qū)不可寫。 進程運行前，將系統(tǒng)空間切換到進程空間，讓系統(tǒng)在受m m u 保護的模式下運 行。 劃分兩塊空問的目的是為了提高運行效率，但會增加內存，增加的內存被用來 存放頁表。如果c p u 采用p p c ，當實際物理內存為2 5 6 m 時，頁表占用的內存空 間推薦為2 m 。因此，以多出2 m 的內存來換取運行效率，代價不大。如果想追求 更高的效率，可以考慮采用更多套頁表。目前的設計只采用兩套頁表，并且在頁 表切換完成后刪除原先的系統(tǒng)頁表。 對于全局變量的保護，采用下列方法。 將全局變量組織成一個結構( 由各個進程自己完成) 。在進程上電的時候調用 支撐層提供的全局變量注冊函數。全局交量注冊函數的入口參數是結構指針的指 針和結構的長度。注冊時，根據長度分配頁尺寸整數倍的內存，并在p c b 表中登 記本進程有使用這一全局變量的權限。其它使用這些全局變量的進程也調用該注 冊函數，如果已經注冊過，則不需要再次為其分配內存。 2 4 2 內存保護范圍 對不同的c p u ，v x w o r k s 的內存排布圖不盡相同，但大致的結構一樣。目前 3 g 統(tǒng)一平臺采用的c p u 主要有三種，種是p o w e r p c ，一種是i n t e lx 8 6 ，還有一 種是a n n 。 p o w e r p c 的內存排布如圖2 8 所示： 1 6 3 g 統(tǒng)一平臺的內存管理研究 圖2 8y x w o r k s 的內存排布圖( p o w e r p c ) 內存保護以頁為單位，因此，所有需要保護的內存大小必須都是頁的倍數。另 外，分配的內存的起始地址必須按頁對齊。統(tǒng)一平臺不支持小于頁尺寸大小的內 存保護。 從圖中可以看出，中斷向量表從頁邊界開始，并且大小是頁的倍數，可以進行 保護。接下來的內存直到初始化棧結束，沒有必要作保護，而且也不可能作保護。 v x w o r k s 開始的t e x t 段必須做保護，這樣做的前提是t e x t 段必須從頁邊界開始， 而且大小也必須是頁的倍數。 w d b 內存池不作保護。 中斷棧作保護。 自由內存區(qū)作可選擇的保護。實際上，內存保護的主要工作是在自由內存部分。 因為，進程的棧和私有數據區(qū)都在自由內存區(qū)中分配。保護的策略和方法主要采 用頁表切換的方法實現(xiàn)。 2 4 3 全局變量保護 全局變量保護需要應用來配合完成，主要目的是為應用提供一種定位問題的手 段。全局變量注冊函數只能在進程上電的時候調用。 第二章內存管理模塊 圖2 9 全局內存保護注冊流程 為了支持全局內存保護，在p c b 中加入兩個字段： b y t e + p u c p r o t e c t g l o a b l d a t a ；嚴指向全局保護內存+ w o r d 3 2d w p r o t e c t g l o a b l d a t a l e n ；，保護區(qū)長度+ 2 。4 4 可測試性設計 2 4 4 1 測試范圍 保護的測試重點在于進程私有數據區(qū)被非法訪問時，能不能觸發(fā)異常。 2 4 4 2 測試方法 1 創(chuàng)建兩個進程，分別為進程a 和進程b 。打開內存保護開關，在進程a 中 1 8 3 g 統(tǒng)一平臺的內存管理研究 直接訪問進程b 中的私有數據區(qū)，則會觸發(fā)異常。 2 遞歸調用同一函數，通過不斷加大嵌套次數，在可預測的次數內，可以觸 發(fā)異常。 3 動態(tài)保護進程棧和私有數據區(qū)，在進程運行中只允許操作本進程的資源。 出現(xiàn)非法訪問?；蛩接袛祿^(qū)時，觸發(fā)異常。 4 在進程棧和私有數據區(qū)之間插入保護頁，并將保護頁屬性設為只讀，出現(xiàn) 訪問越界時觸發(fā)異常。在設置內存訪問屬性后，注意回避一種情況，x 8 6 和a r m 上棧越界到只讀內存，會死機。這與v x w o r k s 在不同c p u 的異常實現(xiàn)有關，而目 前采用的v x w o r k s 操作系統(tǒng)不支持這種異常的處理。 第三章系統(tǒng)u b 動態(tài)管理模塊設計 1 9 第三章系統(tǒng)u b 動態(tài)管理模塊設計 3 1 模塊描述 系統(tǒng)u b 動態(tài)管理模塊是做為原內存管理模塊的補充設計而存在的，在o s s 系統(tǒng)中的位置如圖3 1 所示： 圖3 1 內存管理在0 s s 中的位置 現(xiàn)存的內存管理模塊具有設計簡單、實時性強、效率高等優(yōu)點，但使用靜態(tài)配 置u b 的方法很難避免配置上不合理所帶來問題( u b 缺失或浪費) 。內存管理的 輔助功能( 向上申請及系統(tǒng)對內存擴展) 在一定程度上緩解了u b 配置問題，但又會 帶其它一些問題。比如向上申請會引起實時性變弱；系統(tǒng)堆內存擴展將v x w o r k s 本身內存管理的碎片問題暴露出來。 為解決上述問題，在保證現(xiàn)有u b 管理優(yōu)點的基礎上，并考慮盡量合理有效的 利用內存資源，將“交換塊( sb l o c k ) ”的概念引入到u b 管理中來。引入“交換 塊”的概念后，實際上是在目前u b 管理的基礎上增加了一個層次，向內存池申請 u b 時，先要獲取一個可用的交換塊，進而獲取己可用u b 。交換塊可以被多個內 存池交替使用，根據u b 尺寸的大小，個交換塊被分解成若干u b 。交換塊u b 動態(tài)管理機制可以解決u b 池間內存不能共享等問題。 對于u b 保護，考慮到原來設計方案在打開u b 保護功能時會浪費很多內存， 甚至導致系統(tǒng)由于內存不夠而不能正常啟動，在設計時考慮支持動態(tài)打開u b 保護 功能，并支持對個別內存池進行保護，當然在內存資源夠用時可以對全部u b 池進 行保護。 3 g 統(tǒng)一平臺的內存管理研究 3 2 模塊設計 系統(tǒng)u b 動態(tài)管理模塊包括3 個子模塊。空閑sb l o c k 管理子模塊、系統(tǒng)u b 使用管理子模塊、系統(tǒng)u b 保護子模塊。 3 2 1 空閑sb l o c k 管理子模塊 3 2 1 1 交換塊的相關概念 交換塊( sb l o c k ) 是為多個內存池所共享的一大塊內存，每個交換塊由1 個交換 塊控制塊和若干同等數量的u b 頭和u b 體組成。在某一時刻一個交換塊或者為一 個u b 池所有，或者在空閑交換塊管理器中等待一個u b 池使用。在同一時刻，任 意兩個u b 池不可能同時擁有對同一個交換塊的使用權。一個交換塊如果不再被一 個u b 池使用，需要歸還到空閑交換塊管理器中，等待被其它u b 池使用。 根據目前系統(tǒng)u b 使用的實際情況，并考慮到系統(tǒng)中頁尺寸的大小為4 k ，便 于做u b 保護和避免內存浪費，可采用大小分別為4 k 和3 2 k 兩種尺寸的sb l o c k 。 各內存池根據其管理u b 的大小選擇使用何種尺寸的sb l o c k 。 雖然當前u b 尺寸、個數的配置不太合理，但也存在一定意義上的可參考性。 可以根據目前系統(tǒng)u b 的配置情況折算出所需相應大小sb l o c k 的初始個數，初始 化時這些sb l o c k 不歸任何u b 池所有，而是統(tǒng)一放在空閑交換塊管理器中。當空 閑交換塊中的初始配置的s b l o e k 都被用完時，空閑塊管理器負責向系統(tǒng)堆內存申 請內存并生成新的可用sb l o c k ?？紤]到當前u b 配置中提供了保留u b 的功能， 需要提供一定數目的保留s b l o c k 供定時器模塊申請u b 時使用。按照上述所說，s b l o c k 可以分為靜態(tài)配置的，動態(tài)申請的和保留的三種類型。 s b l o c k 類型： s b l o c kt y p ed y n a m 工c s b l o c kt y p ec o n f 工g s b l o c kt y p er e s e r v e 3 2 1 2 空閑sb l o c k 管理 t 動態(tài)申請+ + 靜態(tài)配置+ + 保留類型+ 空閑sb l o c k 是由空閑sb l o c k 管理器管理的，空閑sb l o c k 管理器通過兩個隊 列分別管理為大小4 k 和3 2 k 的sb l o c k 。初始化時，根據當前系統(tǒng)u b 的配置情 第三章系統(tǒng)l i b 動態(tài)管理模塊設計 2 l 況折算出所需s b l o c k 的尺寸及數量，并從系統(tǒng)堆內存中申請相應尺寸及數量的內 存用做交換塊( sb l o c k ) ，然后初始化這些sb l o c k 為靜態(tài)配置類型并將其添加到 相應的隊列中。初始化過程如圖3 1 2 所示： 流程描述如下： 圖3 2 空閑sb l o c k 初始化過程 3 g 統(tǒng)一平臺的內存管理研究 進行合法性檢查，主要檢查空間交換塊配置表數據是否正確。 獲得頁尺寸大小。 計算虛擬內存總空間，總空間的計算是根據交換塊的尺寸和數目來確定 的，每個交換塊之間間隔一段保護頁。 調用v o s 提供的虛擬內存申請函數，保留一段虛擬內存( 包括交換塊及 交換塊間的保護頁) ，這段內存初始狀態(tài)為不可訪問。 創(chuàng)建并初始化一個鏈表用來維護空閑交換塊。 按交換塊的個數進行循環(huán)。 提交一個交換塊內存，并使這段內存可讀寫。 初始化空閑交換塊，主要初始化塊中用來維護l i b 使用的鏈表結構以及用 來指向當前可用的u b 頭的指針，同時標記交換塊的類型為 s b l o c k t y p e c o n f i g 9 將空閑交換塊加入隊列中。 1 0 在交換塊的后面保留一段虛擬內存作為保護頁，對于4 k 和3 2 k 的交換塊 保護頁的大小分別為4 k 和3 2 k 。 當u b 池向空閑sb l o c k 管理器申請一個可用的sb l o c k 時，空閑交換塊管理 器從相應隊列獲取sb l o c k 給申請者使用；當l i b 池向空閑sb l o c k 管理其歸還一 個sb l o c k 時，交換塊管理器將該sb l o c k 添加到相應隊列中。 當u b 池向空閑sb l o c k 管理器申請sb l o c k 時，如果對應的隊列已經為空， 空閑sb l o c k 管理器向系統(tǒng)堆內存申請一定尺寸的內存生成新的sb l o c k ，并做相 關的初始化同時標記次sb l o c k 為動態(tài)申請類型。 對于動態(tài)申請類型的sb l o c k ，當u b 池將其向空閑sb l o c k 管理歸還時，需要 根據事先選擇的策略決定是否向系統(tǒng)堆內存歸還，這里所講的策略可能有以下兩 種，可以通過變量控制究竟使用何種策略： 1 對于4 k 的sb l o c k ，靜態(tài)配置不夠時向堆內存申請，sb l o c k 歸還時不釋 放內存而是加入空閑sb l o c k 隊列；對于3 2 k 的sb l o c k ，靜態(tài)配置不夠時 不向堆內存申請擴展sb l o c k 。 2 對于4 k 的sb l o c k ，策略同上；對于3 2 k 的sb l o c k ，靜態(tài)配置不夠時向 堆內存申請擴展sb l o c k ，當此sb l o c k 歸還時釋放其所在的內存。 3 對于4 k 的sb l o c k 和3 2 k 的sb l o c k 一樣處理，即空閑塊用完時向堆內存 申請擴展sb l o c k ，歸還時不釋放。 圖3 3 ，3 4 分別描述了向sb l o c k 管理器申請和歸還的流程： 1 2 3 4 5 6 7 8 第三章系統(tǒng)u b 動態(tài)管理模塊設計 圖3 3 申請空閑sb l o c k 流程 3 g 統(tǒng)一平臺的內存管理研究 圖3 4 歸還空閑sb l o c k 流程 3 2 2 系統(tǒng)u b 使用管理子模塊 系統(tǒng)l i b 使用管理子模塊主要基于交換塊動態(tài)管理技術，描述了動態(tài)管理的層 次結構、模塊初始化流程、u b 申請釋放流程以及u b 使用管理的輔助功能u b 使 用告警和u b 使用統(tǒng)計。 3 2 2 1 交換塊動態(tài)管理的層次結構 ( 1 ) u b 池的分層結構 基于交換塊的u b 動態(tài)管理方法從大的層次結構上來看，可分為u b 池層、交 換塊( sb l o c k ) 層和u b 頭體層三個層次，層次結構示意如圖3 - 5 所示。對每一 個層的具體描述如下： 1 u b 池 相同尺寸的u b 屬于同一個u b 池，每個u b 池有一個u b 池控制塊和若 干交換塊( sb l o c k ) 組成。u b 池控制塊用于管理l i b 池中的交換塊，其中交 換塊的個數不固定可以根據需要增加或減少，即u b 池中的u b 的總數是動態(tài) 第三章系統(tǒng)l i b 動態(tài)管理模塊設計 變化的。 為了合理利用交換塊，避免浪費過多的內存空間，按照管理的u b 尺寸大 小將u b 池分成1 0 個，每個u b 池管理的u b 尺寸分別為6 4 、1 2 8 、2 5 6 、5 1 2 、 9 6 0 、1 9 8 4 、3 9 6 8 、8 1 2 8 、1 6 3 2 0 、3 2 6 4 0 字節(jié)。 2 交換塊( s b l o c k ) 向前面所描述的，將交換塊分成4 k 和3 2 k 兩種固定尺寸，每個交換塊由 一個交換塊控制塊和若干同等數量的u b 頭和u b 體組成，交換塊控制塊用于 管理交換塊內部的u b 頭和u b 體。由于交換塊的尺寸固定，當根據不同尺寸 的l i b 劃分交換塊時，所得到的u b 個數不同。各u b 池根據其管理u b 尺寸 大小的不同選擇使用4 k 還是3 2 k 的交換塊。 3 l i b 頭( u b h e a d ) u b 頭與u b 體一一對應，作為u b 體的控制塊，保存u b 體的使用信息。 4 u b 體( u b ) u b 體為提供給申請者實際使用的連續(xù)內存單元。 圖3 5 交換塊動態(tài)管理的分層結構 ( 2 ) u b 池控制塊結構 前面已經說過u b 池控制塊是用來管理交換塊的，u b 池控制塊通過其維護的 數據結構知道哪些交換塊是可用的( 交換塊內有可使用的u b ) ，哪些交換塊是不 可用的( 交換塊內無可用u b ) ，哪些交換塊是保留交換塊。如圖3 6 所示，u b 池 控制塊維護了四個鏈表：可用交換塊鏈表、用滿交換塊鏈表、保留交換塊鏈表和 未保護交換塊鏈表。下面對u b 池控制塊數據結構各項做一下說明： 1 可用交換塊鏈表：用來管理u b 池中可用sb l o c k 的雙向鏈表，當鏈表中 的某個sb l o c k 的u b 都用盡時，該sb l o c k 將被轉移到用滿交換塊鏈表 中：當鏈表中的某個sb l o c k 的所有u b 都不再被使用時，該sb l o c k 將被 3 g 統(tǒng)一平臺的內存管理研究 歸還到空閑交換塊管理器中?？紤]到u b 申請的效率以及防止發(fā)生在申請 空閑塊和歸還空閑塊間震蕩，歸還交換塊時可不將空閑交換塊從可用交換 塊鏈表中摘除。 2 用滿交換塊鏈表：用來管理u b 池中不可用sb l o c k 的雙向鏈表，當鏈表 中的某一個sb l o c k 的某個u b 被歸還時，該sb l o c k 變?yōu)榭捎?，并根據s b l o c k 的類型將被轉移到可用交換塊鏈表或保留交換塊鏈表中。 3 保留交換塊鏈表：用來管理u b 池中保留sb l o c k 的雙向鏈表，由于目前 只有定時器模塊用到了大小為“字節(jié)的保留u b ，可以在u b 池初始化時， 為管理6 4 字節(jié)的u b 池分配兩個sb l o c k 添加到保留交換塊鏈表中。與可 用交換塊管理不同的是保留sb l o c k 不用歸還到空閑交換塊管理器中。 4 未保護交換塊鏈表：用來管理u b 池中不被保護的sb l o c k 的雙向鏈表， 該鏈表只有在支持u b 保護的情況下才有用，在后面u b 保護子模塊中將 進一步介紹。 5 l i b 大?。罕硎疽粋€u b 池所支持申請的u b 尺寸大小。 6 交換塊的u b 個數：該u b 池管理的sb l o c k 中的u b 個數，由于每個sb l o c k 中能夠劃分的u b 個數在同一u b 池中相同，因此該個數可存放在控制塊 中。 。拍b b竺竺 8bloat忸d l m 麗 憶竺苧竺 s “o c k t m l l i s t ；而 r e s e m型 8b l o c kt a i ：百 u n p r 。t 日竺型 sb l o c k乜 i s t 石而 u bs i z e n l j m l no n e s n o e k k a k c 州 圖3 61 j b 池控制塊結構示意圖 ( 3 ) 交換塊控制結構 正如前面所描述過的，交換塊控制塊時用來管理交換塊內部的u b 頭和u b 體的，其結構如圖3 7 所示，結構組成描述如下： 1 節(jié)點：交換塊在u b 池中是以節(jié)點的形式存在于相關的鏈表中的，交 第三章系統(tǒng)u b 動態(tài)管理模塊設計 2 7 換塊是通過節(jié)點一個個的連接被管理起來的。 2 空閑u b 控制鏈表；用來管理交換塊中空閑u b 的一個雙向鏈表，實 際鏈表中記錄了空閑u b 頭的位置，即u b 頭作為鏈表中的一個節(jié)點。 當有申請者向交換塊申請u b 時，從空閑u b 控制鏈表的頭部取出對 應的u b ，并轉移到已用u b 控制鏈表的尾部。 3 己用u b 控制鏈表：用來管理正在被使用u b 的一個雙向鏈表，當鏈 表中的u b 被申請者歸還時，將u b 節(jié)點從該鏈表中摘除并添加到空 閑u b 控制鏈表的尾部。 4 u b 個數 5 u b 池控制塊指針：用來保存該交換塊所在位置( 在哪個u b 池中) 的 地址指針。 6 下一個可用l i b 頭指針：當空閑u b 控制鏈表為空若且交換塊中還有 可用u b 時，該指針指向了當前可用的u b 頭。 r 口一 n e x t o r e v 竺! u b t a i 。 l i s t 麗 u 5 e d型 u b d 了it a i l l i s t 贏 u bo i 靠p b n 嘲u be t dd ” 圖3 7 交換塊控制塊結構示意圖 ( 4 ) u b 頭體數據結構 u b 頭和u b 體都存在于某個交換塊的內部，根據u b 體大小的不同交換塊 被分割的u b 頭體的個數也會不同。在物理位置上可以采用“頭體合一、尾部 提交的”的方法，如圖3 8 所示，u b 頭和u b 體在物理上是連續(xù)存放的?？?慮到u b 保護，采用尾部提交方式，即u b 申請者實際使用的內存為u b 體后 面的一段，這樣u b 體的頭部需要占用4 個字節(jié)用于存放u b 頭指針。 圖3 8 頭體合一、尾部提交的存儲方式 u b 頭作為記錄u b 體使用情況的結構，由以下幾部分組成： 1 節(jié)點：u b 頭作為交換塊控制塊某個鏈表的一個節(jié)點被管理前來的。 2 實際使用尺寸：用來記錄申請者實際使用了多大的內存空間。 3 g 統(tǒng)一平臺的內存管理研究 3 用戶使用信息：用來記錄u b 申請者相關信息。 ( 5 ) u b 池中各實體