將運行時事件與組件相關聯(lián)的方法和系統(tǒng)的制作方法

專利名稱：將運行時事件與組件相關聯(lián)的方法和系統(tǒng)的制作方法
技術領域：
本發(fā)明 一般涉及計算機領域，特別是將運行時事件與組件相關聯(lián) 的方法和系統(tǒng)。
背景技術：
在合作環(huán)境中，組件間存在復雜的互依存關系，并且確定資源的 真實消費者非常令人迷惑。在合作過程期間， 一個組件通常代表另 一個組件消費資源。圖l示出了這種情形。圖1示出了現(xiàn)有技術中一個富客戶端平臺(RCP, Rich Client Platform),它是Lotus客戶端的核心。RCP基于OSGI規(guī)范，OSGI 規(guī)范具有在不同組件間頻繁發(fā)生合作的特征。在此情況中，應該隨 著不同組件的角色和運行時上下文做出不同的記賬決定。圖l示出 了 HTTP請求的典型過程流。當"HTTP組件"接受一個業(yè)務請求時， 它將過程完全分配給"服務小程序組件1-n",它們將調(diào)用用于功能過 程的"工具組件"。當"HTTP組件，，接受來自于管理員的請求以配 置相關系統(tǒng)時，它將調(diào)用"配置處理器組件"用于功能過程。根據(jù) 不同的相關配置的分類，它將調(diào)用"XML處理器組件"或者"DB 處理器組件"。顯然，"工具組件"代表服務小程序消費資源。但 是服務小程序負責它自己的資源消費。為了分析此環(huán)境中的資源消 費，原來的方法是不能勝任的。因此，需要在此環(huán)境中發(fā)現(xiàn)資源的真實消費者，這對于在合作環(huán) 境中做出資源使用情況的清晰分析、做出有效的性能診斷和認識到 主要消費點非常重要。為了了解軟件組件的資源使用，并且這將對于完善組件設計、運行時過程或者安全做出變化需要有所幫助，已 經(jīng)有了一些涉及資源記賬的努力。但是它們都具有缺點，這些缺點
使它們不適合解決上述問題。當前的方法沒有考慮合作組件間資源 的真實消費者。這些方法僅關注單個組件的資源消費。在合作環(huán)境 中，在沒有考慮組件間關系以及沒有反映組件和運行時環(huán)境的情況 下，不可能做出明智的記賬決定。這樣，很難基于當前方法直接解 決上述問題。首先，當前對用于資源記賬的兩個主要單元是線程和隔離(一種封裝的Java程序或者不與其他的組件共享狀態(tài)的應用組件)。很難 將不同種類的組件映射到這兩個單元。大部分組件模型獨立于線程 并且在不同組件間具有互依存關系。因此，缺乏對于通常組件單元 的支持使當前方法難于作為基礎使用。其次，這些方法依靠機械的代碼手段。它們提供接口和相關實現(xiàn) 的定義并將它們插入代碼，這很難隨不同環(huán)境做出改變。因此，在 此環(huán)境下，需要發(fā)現(xiàn)新的方法以解決資源的真實消費者問題并且做 出有效的記賬。發(fā)明內(nèi)容本發(fā)明的一個目的是將運行時事件與組件相關聯(lián)。這樣，當一 些重要的事件發(fā)生時，能夠捕捉到精確的上下文，例如，誰在什么 條件下刪除了一個文件或哪個組件應當為系統(tǒng)崩潰負責。此外，通 過將運行時事件與組件相關聯(lián)，還能夠識別那個組件違反了系統(tǒng)原 則以及發(fā)現(xiàn)系統(tǒng)中易受攻擊的點。本發(fā)明的另 一個目的是在有復雜的互依存關系的組件組成的系 統(tǒng)中確定哪個組件實際消費了資源。根據(jù)本發(fā)明的 一個方面，提供一種將運行時事件與組件相關聯(lián) 的方法，包括獲取運行時事件；獲取當前運行環(huán)境的上下文并根 據(jù)所述上下文確定當前組件；獲取當前組件的關聯(lián)策略并根據(jù)所述 關聯(lián)策略確定與所述運行時事件相關聯(lián)的負責組件。根據(jù)本發(fā)明的另 一個方面，提供一種將運行時事件與組件相關 聯(lián)的系統(tǒng)，包括事件監(jiān)視器，用于獲取運行時事件；上下文監(jiān)視 器，用于獲取當前運行環(huán)境的上下文并根據(jù)所述上下文確定當前組件；推理引擎，用于獲取當前組件的關聯(lián)策略和根據(jù)所述關聯(lián)策略 確定與所述運行時事件相關聯(lián)的負責組件。


通過對結合附圖所示出的實施方式進行詳細說明，本發(fā)明的上述 以及其他特征將更加明顯，本發(fā)明附圖中相同的標號表示相同或相 似的部件。在附圖中，圖1示出在合作環(huán)境中組件間存在復雜的互依存關系的示意圖； 圖2示出按照本發(fā)明的一個實施例的為各個組件附加策略標簽 的示意圖；圖3示出按照本發(fā)明的一個實施例的將運行時事件與組件相關 聯(lián)的方法的流程圖；圖4示出按照本發(fā)明的一個實施例的將運行時事件與組件相關 聯(lián)的系統(tǒng)的方框圖；圖5示出按照本發(fā)明的另一個實施例的將運行時事件與組件相 關聯(lián)的系統(tǒng)的方框圖；圖6示出適于實施本發(fā)明的計算機系統(tǒng)的結構方框圖。
具體實施方式
圖2示出按照本發(fā)明的一個實施例的為各個組件附加策略標簽 的示意圖。圖2中的富客戶端平臺中的組件與圖1中的組件有相同 的互依存關系。本發(fā)明中，為各個組件附加了一個表示運行時事件 與該組件之間的關聯(lián)策略的標簽，即策略標簽。以下將會結合實施 例乂寸此進4亍詳細i兌明。圖3示出按照本發(fā)明的一個實施例的將運行時事件與組件相關 聯(lián)的方法的流程圖。在步驟301，將策略標簽與各個組件相關聯(lián)。這個步驟可以是在 設計階段通過多種方式實現(xiàn)。
在Jave程序中可以通過Java注釋來實現(xiàn)策略標簽與組件的關聯(lián)。 注釋是J2SE5.0(Tiger)中的一個新功能，它為核心Java語言帶來必 要的元數(shù)據(jù)工具。注釋是對代碼的修改并應用于包聲明、類型聲明、 構造器、方法、字段、參數(shù)和變量。這樣可以利用在代碼中插入注 釋來為以后的記賬處理提供重要的參考。置。例如，在獨立的配置文件中存儲一個或多個組件的組件名稱以 及它所對應的關聯(lián)策略標簽等等。另外，還可以為各個組件針對調(diào) 試、系統(tǒng)安全或系統(tǒng)測試等多個不同的目的準備多組關聯(lián)策略標簽。 在運行時針對不同目的選擇其中的一組。專門的API。當需要獲取組件的策略標簽時，可以調(diào)用該API。 接下來將詳細描述在執(zhí)行階段將運行時事件與組件相關聯(lián)的過程。在步驟302,獲取運行時事件。至少可以通過主動采樣或由事件 被動觸發(fā)而獲取事件。例如可以通過主動采樣來獲取 一 個時間間隔 內(nèi)消耗的CPU時間。對于打開文件句柄、套接字或分配存儲器這樣 的事件可以被動地觸發(fā)來獲取運行時事件。在步驟303,獲取當前運行環(huán)境的上下文并根據(jù)所述上下文確定 當前組件。其中，獲取當前運行環(huán)境的上下文可以是通過堆棧巡視 器獲取堆?？煺詹⒒陧敹褩瑏泶_定當前組件?；蛘?，可以通過 查看執(zhí)行日志來確定當前組件。執(zhí)行日志是在程序執(zhí)行過程中記錄 組件調(diào)用過程的。當執(zhí)行過程進入新的組件時，該組件的信息(包 括組件的策略標簽)和它們的策略被記錄進日志；當執(zhí)行過程退出 某一組件時，該信息也被記錄進日志。通過這樣的方式，執(zhí)行日志 真實的體現(xiàn)了當前運行時環(huán)境。這樣，可以通過查看執(zhí)行日志來查 找當前組件。堆棧的快照和執(zhí)行日志都可以反映當前運行環(huán)境，都 可以用于查找當前組件及其相關策略標簽。本發(fā)明只是示例性地給 出了獲取當前運行環(huán)境的上下文的幾種方式，事實上，本領域技術 人員可以采用目前獲取當前運行環(huán)境的上下文的各種方式來實現(xiàn)本 發(fā)明。在步驟304，判斷當前組件或關聯(lián)策略是否改變。如果未改變， 說明在事件發(fā)生時，運行堆棧中的當前組件和相關策略沒有改變。 那么可以判斷為該事件負責的組件和上 一 事件相同，即可直接利用 上次事件發(fā)生時的分析結果得出負責組件。這樣，直接執(zhí)行步驟306, 以更新負責組件的統(tǒng)計。應當理解，步驟304是一個可選的步驟， 目的是節(jié)省其他判斷負責組件的步驟以提高效率。如果步驟304的判斷結果是否，則進行步驟305,獲取當前組件 的關聯(lián)策略并根據(jù)所述關聯(lián)策略確定與所述運行時事件相關聯(lián)的負 責組件。在策略標簽附加到組件的情況下，策略標簽是與組件一起裝載到 執(zhí)行堆棧中的。這樣，在堆?？煺罩屑扔薪M件又有組件的策略標簽。 當前組件所附加的策略標簽可以>^人所述快照中獲取。相似地，當程 序執(zhí)行進入一個組件時，取出它包含的標簽并把標簽和組件信息寫 進日志。這樣，同樣可以從日志中取得當前組件所附加的策略標簽。在策略標簽存儲在策略存儲裝置中的情況下，則可以讀取策略存 儲裝置中的所述策略標簽。例如，通過當前組件名檢索策略存儲裝 置中的該組件所對應的策略標簽或打開當前組件所對應的配置文件 以讀取該組件的策略標簽。此外，還可以調(diào)用專用的API來獲得當前組件的策略標簽。策略標簽可以是以下標簽中的一個或多個Parent, Self, Caller， Classloader, Common, Allocater， Boundary, Leakbot和HeapAnalyzer。 應當理解，根據(jù)不同目的可以設計其他策略標簽。根據(jù)關聯(lián)策略確定與所述運行時事件相關聯(lián)的負責組件可以按 如下方式實現(xiàn)當策略標簽為Self時，則確定當前組件為負責組件；當策略標簽為Parent時，則確定創(chuàng)建該線程的父組件為負責組件；
當策略標簽為Caller時，則確定調(diào)用當前組件的組件為負責組件；當策略標簽為Classloader時，則確定裝載當前組件的系統(tǒng)組件 為負責組件；當策略標簽為Common時，則確定提供公共服務的組件為負責 組件；當策略標簽為Allocater時，則確定與資源相關聯(lián)的分配器為負 責組件；當策略標簽為Boundary時，則確定位于執(zhí)行堆棧中最上面的組 件為負責組件。在采用執(zhí)行日志的方式下，因為堆棧最上層的組件 在執(zhí)行過程中已經(jīng)被記錄到日志中，并且作為最后被寫入的內(nèi)容可 以>(人日志中識別出來。根據(jù)關聯(lián)策略的設計，例如需要判斷父組件或當前組件的調(diào)用者 時，需要保存所述執(zhí)行堆棧的軌跡。根據(jù)所述執(zhí)行堆棧的軌跡的遞 歸，查找父組件或當前組件的調(diào)用者等。在步驟306，更新負責組件的統(tǒng)計。在得到運行時事件和它的負 責組件后，可以將它們記錄到日志中或統(tǒng)計池中，用于以后的系統(tǒng) 分析。應當理解，步驟306是可選的步驟。例如，在調(diào)試過程中得 到運行時事件與負責組件的關聯(lián)后，顯示該關聯(lián)關系也是可以的。在曰志或統(tǒng)計池中記錄運行時事件與負責組件的關聯(lián)后，可以反 映運行時的上下文。這樣，可以記錄誰在什么條件下刪除了一個文 件或哪個組件應當為系統(tǒng)崩潰負責。此外，通過將運行時事件與組 件相關聯(lián)，還能夠識別那個組件違反了系統(tǒng)原則以及發(fā)現(xiàn)系統(tǒng)中易 受攻擊的點。在曰志或統(tǒng)計池中記錄運行時事件與負責組件的關聯(lián)后，可以確 定在有復雜的互依存關系的組件組成的系統(tǒng)中哪個組件實際消費了 資源。使得記賬處理更加準確。將運行時事件與組件相關聯(lián)是有優(yōu)勢的。首先，由組件組成的系 統(tǒng)時相互獨立開發(fā)和交付的。每個組件是自治的，也就是每個組件
自己管理它的資源，包括執(zhí)行它的功能所使用的堆空間。每個組件 負責分配它需要的堆空間并在不使用時釋放它。這使得組件成為堆 管理的一個單元。這樣，本發(fā)明在管理由第三方組件構成的系統(tǒng)時 非常有用。例如，給所有第三方組件附加策略標簽，可以識別對系 統(tǒng)的堆錯誤負責的組件。這樣可以替換錯誤的組件或要求該組件的 供應商修改該錯誤。利用本發(fā)明的方法還可以幫助查找熱點。當前的熱點跟蹤是方法 級的。由于方法的數(shù)量通常是非常大的，基于方法的熱點跟蹤的系 統(tǒng)開銷非常大，并且容易失去主要的關注點。本發(fā)明中的組件是任 意粒度的，，可以是一個方法，也可以是一個類，或者一個包，甚 至幾個包的組合。這樣，采用本發(fā)明可以實現(xiàn)基于組件的熱點跟蹤， 而實現(xiàn)基于組件的熱點跟蹤也更為容易?，F(xiàn)有的熱點追蹤主要依賴當前線程的運行堆棧，當創(chuàng)建新線程時 新的堆棧被使用，導致新線程丟失了父線程的信息。這樣原始執(zhí)行 上下文的丟失會帶來決策上的混淆甚至錯誤。本發(fā)明中在組件中附加Parent標簽，可以找到父線程，這樣就解決了該問題，使得統(tǒng)計 熱點時更加準確。在現(xiàn)有的熱點跟蹤中，靜態(tài)資源的初始化通常被記賬到激活它的 第 一個實例之上。由于靜態(tài)資源是為同 一類的所有實例所共享的， 這種記賬是不公平的。在本發(fā)明中用Classloader標簽，靜態(tài)資源被 記賬到類加載器，使得記賬更為準確。一些現(xiàn)有的熱點跟蹤方法利用門限值排除資源計算的對象。當某 一方法的資源消耗低于該門限值時，將不再跟蹤該方法的調(diào)用分支， 這樣造成跟蹤過程中的信息丟失和分析的誤差。本發(fā)明中在組件中 附加Boundary標簽，指明需要跟蹤和資源記帳的范圍，例如應用中 線程池的使用。作為一種常見的編程模式，程序在運行過程中生成 并持有若干線程為不同的請求服務。這些線程消耗的資源與本身無 關，而是由于執(zhí)行用戶請求造成的。本發(fā)明將通過標志它們?yōu)?Boundary標簽，而把這些線程消^^的資源自動地記在當前運^f亍組件
的帳上，從而解決了這一問題。利用本發(fā)明的方法還可以幫助查找內(nèi)存泄漏點。在本發(fā)明中可以采用例如Leakbot或HeapAnalyzer標簽找到漏點的候選者。對于候 選者標注Allocater標簽則可跟蹤內(nèi)存分配和釋放事件。在一段時間 后，導出所有對象的分配、釋放事件和事件發(fā)生時的堆棧。除去對 應與同一對象的內(nèi)存分配和釋放事件，分析剩下的事件及其相應的 堆?？梢詭椭页鲈斐蓛?nèi)存泄漏的真正原因。圖4示出按照本發(fā)明的一個實施例的將運行時事件與組件相關 聯(lián)的系統(tǒng)的方框圖。本發(fā)明的將運行時事件與組件相關聯(lián)的系統(tǒng)包 括事件監(jiān)視器410,上下文監(jiān)視器420和推理引擎430。此外還可以 包括策略存儲裝置440和統(tǒng)計池450。事件監(jiān)視器410用于獲取運行時事件。事件監(jiān)視器410通過主動 采樣或由事件被動觸發(fā)而獲取事件。例如可以通過主動采樣來獲取 一個時間間隔內(nèi)消^^的CPU時間。對于打開文件句柄、套4妄字或分 配存儲器這樣的事件可以被動地通過各個資源的適配器411、 412和 413觸發(fā)來獲取運行時事件。適配器411-413的實現(xiàn)與資源的類型相 關。適配器411-413可以是事件處理器或?qū)Y源進行定期采樣的采樣 線程。當事件監(jiān)視器410獲取一個事件后，通知推理引擎430。推理引 擎430通知上下文監(jiān)視器420獲取當前運行環(huán)境的上下文并根據(jù)所 述上下文確定當前組件。上下文監(jiān)視器420可以是一個堆棧巡視器 或者是一個執(zhí)行日志讀取器。堆棧巡視器獲取執(zhí)行堆棧的快照，執(zhí) 行日志讀取器讀取程序執(zhí)行過程中被記錄下來的組件調(diào)用過程。堆 棧的快照與執(zhí)行日志都是當前運行環(huán)境的上下文，都可以用于確定 當前組件。此外，上下文監(jiān)視器420還可以遍歷所述上下文。如果 需要，可以遍歷上下文遞歸地確定當前組件的父組件或當前組件的 調(diào)用者等等。當上下文監(jiān)視器420獲得當前組件后通知推理引擎 430?？蛇x地，推理引擎430帶有一個緩存，存儲上一次事件對應 組件和策略比較，推理引擎進一步判斷當前組件或關聯(lián)策略是否改 變，如果改變，推理引擎進一步確定與所述運行時事件相關聯(lián)的負 責組件；否則，直接引用被緩存的負責組件作為本次事件的分析結 果。推理引擎430獲取當前組件的關聯(lián)策略和根據(jù)所述關聯(lián)策略確 定與所述運行時事件相關聯(lián)的負責組件。在策略標簽附加到組件的情況下，策略標簽是與組件l-n—起裝 載到執(zhí)行堆棧l-n中的。圖5示出在Java環(huán)境下實現(xiàn)本發(fā)明的情況。 其中注釋器510可以在組件的設計階段將標識關聯(lián)策略的注釋附加 到組件l-n中。帶有已注釋組件被加載器520加載到堆棧l-n。這樣， 在堆棧快照中既有組件又有組件的策略標簽。當前組件所附加的策 略標簽可以從所述快照中獲取。返回圖4。組件的策略標簽可以存儲在策略存儲裝置440中。策 略存儲裝置440可以是每個組件各有一個配置文件，也可以是所有 的策略標簽都存儲在一個配置文件。推理引擎430可以讀取讀取各 個配置文件中策略標簽，或者通過例如當前組件名檢索策略存儲裝 置中的該組件所對應的策略標簽。此外，推理引擎430還可以調(diào)用專用的API來獲得當前組件的 策略標簽。如果推理引擎430需要判斷父組件或當前組件的調(diào)用者時，可以 命令上下文監(jiān)視器420執(zhí)行上下文的遞歸，確定與所述運行時事件 相關聯(lián)的負責組件。當推理引擎430獲得當前事件的負責組件后，進一步在統(tǒng)計池 450中更新負責組件的統(tǒng)計圖6示意性示出了可以實現(xiàn)根據(jù)本發(fā)明的實施例的計算設備的 結構方框圖。圖6中所示的計算機系統(tǒng)包括CPU(中央處理單元)601、RAM(隨 機存取存儲器)602、 ROM(只讀存儲器)603、系統(tǒng)總線604,硬盤控 制器605、鍵盤控制器606、串行接口控制器607、并行接口控制器 608、顯示器控制器609、硬盤610、鍵盤611、串行外部設備612、 并行外部設備613和顯示器614。在這些部件中，與系統(tǒng)總線604 相連的有CPU601、 RAM 602、 ROM 603、硬盤控制器605、鍵盤控 制器606,串行接口控制器607,并行接口控制器608和顯示器控制 器609。硬盤610與硬盤控制器605相連，鍵盤611與鍵盤控制器 606相連，串行外部設備612與串行接口控制器607相連，并行外部 設備613與并行接口控制器608相連，以及顯示器614與顯示器控 制器609相連。圖6中每個部件的功能在本技術領域內(nèi)都是眾所周知的，并且圖 6所示的結構也是常規(guī)的。這種結構不僅用于個人計算機，而且用于 手持設備，如PalmPC、 PDA(個人數(shù)據(jù)助理)、移動電話等等。在 不同的應用中，例如用于實現(xiàn)包含有根據(jù)本發(fā)明的客戶端模塊的用可以向圖6中所示的結構添加某些部件，或者圖6中的某些部件可 以被省略。圖6中所示的整個系統(tǒng)由通常作為軟件存儲在硬盤610 中、或者存儲在EPROM或者其它非易失性存儲器中的計算機可讀 指令控制。軟件也可從網(wǎng)絡(圖中未示出)下載?；蛘叽鎯υ谟脖P 610中，或者從網(wǎng)絡下載的軟件可被加載到RAM 602中，并由CPU 601執(zhí)行，以便完成由軟件確定的功能。盡管圖6中描述的計算機系統(tǒng)能夠支持根據(jù)本發(fā)明的提供網(wǎng)絡 內(nèi)容以供脫機使用的方案，但是該計算機系統(tǒng)只是計算機系統(tǒng)的一 個例子。本領域的熟練技術人員可以理解，許多其它計算機系統(tǒng)設 計也能實現(xiàn)本發(fā)明的實施例。本發(fā)明還可以實現(xiàn)為例如由圖6所示計算機系統(tǒng)所使用的計算 機程序產(chǎn)品，其可以包含有用于實現(xiàn)根據(jù)本發(fā)明的提供網(wǎng)絡內(nèi)容以 供脫機使用的網(wǎng)絡應用服務器的代碼；其還可以包含有用于實現(xiàn)根 據(jù)本發(fā)明的用于獲取網(wǎng)絡內(nèi)容以供脫機使用的客戶端模塊的代碼。 在使用之前，可以把代碼存儲在其它計算機系統(tǒng)的存儲器中，例如， 存儲在硬盤或諸如光盤或軟盤的可移動的存儲器中，或者經(jīng)由因特
網(wǎng)或其它計算機網(wǎng)絡進行下載。所公開的本發(fā)明的方法可以在軟件、硬件、或軟件和硬件的結 合中實現(xiàn)。硬件部分可以利用專用邏輯來實現(xiàn)；軟件部分可以存儲 在存儲器中，由適當?shù)闹噶顖?zhí)行系統(tǒng)，例如微處理器、個人計算機 (PC)或大型機來執(zhí)行。上述實施例以Java為例進行了說明。應當理解，本發(fā)明并不限 于Java環(huán)境。本發(fā)明可以用于任何采用了組件的系統(tǒng)，例如Java或 PHP環(huán)境等。雖然已經(jīng)參考目前考慮到的實施例描述了本發(fā)明，但是應該理解 本發(fā)明不限于所公開的實施例。相反，本發(fā)明旨在涵蓋所附權利要 求的精神和范圍之內(nèi)所包括的各種修改和等同布置。以下權利要求 的范圍符合最廣泛解釋，以便包含所有這樣的修改及等同結構和功 能。
權利要求
1. 一種將運行時事件與組件相關聯(lián)的方法，包括獲取運行時事件；獲取當前運行環(huán)境的上下文并根據(jù)所述上下文確定當前組件；獲取當前組件的關聯(lián)策略并根據(jù)所述關聯(lián)策略確定與所述運行時事件相關聯(lián)的負責組件。
2. 根據(jù)權利要求1的方法，其中獲取當前運行環(huán)境的上下文并 根據(jù)所述上下文確定當前組件的步驟包括獲取執(zhí)行堆棧的快照或者 查看執(zhí)行日志，并根據(jù)所述快照或者所述日志確定當前組件。
3. 根據(jù)權利要求1或2的方法，進一步包括 在組件中附加策略標簽；將策略標簽與組件一起裝載到執(zhí)行堆?；虮挥涗涍M入執(zhí)行日志；和獲取當前組件的關聯(lián)策略的步驟進一步包含從所述上下文中獲 取所述附加的策略標簽。
4. 根據(jù)權利要求1或2的方法，進一步包括 在策略存儲裝置中保存組件的至少一組策略標簽；和獲取當前組件的關聯(lián)策略進一步包含讀取策略存儲裝置中的所 述策略標簽。
5. 根據(jù)權利要求1或2的方法，獲取當前組件的關聯(lián)策略進一步 包含調(diào)用專用API獲取所述策略標簽。
6. 根據(jù)權利要求1或2的方法，進一步包括 保存所述運行環(huán)境的軌跡；和遞歸分析當前運行環(huán)境的上下文，確定與所述運行時事件相關 聯(lián)的負責組件。
7. 根據(jù)權利要求1或2的方法，所述策略標簽是以下標簽中的一 個或多個Parent, Self, Caller, Classloader, Common, Allocater, Boundary, Leakbot和Heap Analyzer; 其中當策略標簽為Self時，則確定當前組件為負責組件；當策略標簽為Parent時，則確定創(chuàng)建該線程的父組件為負責組件；當策略標簽為Caller時，則確定調(diào)用當前組件的組件為負責組件；當策略標簽為Classloader時，則確定裝載當前組件的系統(tǒng)組件 為負責組件；當策略標簽為'Common時，則確定提供公共服務的組件為負責 組件；當策略標簽為Allocater時，則確定與資源相關聯(lián)的分配器為負 責組件；當策略標簽為Boundary時，則確定位于執(zhí)行堆棧中最上面的組 件為負責組件。
8. 根據(jù)權利要求1或2的方法，進一步包括 獲取當前運行環(huán)境的上下文后判斷當前組件或關聯(lián)策略是否改變，如果是，則確定與所述運行時事件相關聯(lián)的負責組件。
9. 根據(jù)權利要求1-8中任一個的方法，進一步包括 更新負責組件的統(tǒng)計。
10. 根據(jù)權利要求1-9中任一個的方法，其中通過主動采樣或由 事件被動觸發(fā)而獲取事件。
11. 一種將運行時事件與組件相關聯(lián)的系統(tǒng)，包括 事件監(jiān)視器，用于獲取運行時事件；上下文監(jiān)視器，用于獲取當前運行環(huán)境的上下文并根據(jù)所述上 下文確定當前組件；推理引擎，用于獲取當前組件的關聯(lián)策略和根據(jù)所述關聯(lián)策略確定與所述運行時事件相關聯(lián)的負責組件。
12. 根據(jù)權利要求11的系統(tǒng)，其中上下文監(jiān)視器進一步包括堆棧 巡視器或者執(zhí)行日志更新器，其中堆棧巡視器用于獲取執(zhí)行堆棧的 快照，執(zhí)行日志更新器用于根據(jù)當前程序執(zhí)行情況更新日志信息， 所述上下文監(jiān)視器根據(jù)所述快照或所述日志確定當前組件。
13. 根據(jù)權利要求11或12的系統(tǒng)，進一步包括注釋器，用于 在組件中附加策略標簽；加載器，用于將策略標簽與組件一起裝載到執(zhí)行堆棧；和 所述上下文監(jiān)視器進一步從所述當前運行時的上下文中獲取所 述附加的策略標簽。
14. 根據(jù)權利要求11或12的系統(tǒng)，進一步包括 策略存儲裝置，用于保存組件的策略標簽；和 所述推理引擎進一步讀取策略存儲裝置中的所述策略標簽。
15. 根據(jù)權利要求11或12的系統(tǒng)，其中所述推理引擎調(diào)用專用 API獲取所述策略標簽。
16. 根據(jù)權利要求11或12的系統(tǒng)，其中 所述上下文監(jiān)視器進一步保存所述執(zhí)行環(huán)境的軌跡；和 所述推理引擎遞歸分析當前運行環(huán)境的上下文(堆?；蛘邎?zhí)行曰志)，確定與所述運行時事件相關聯(lián)的負責組件。
17. 根據(jù)權利要求11或12的系統(tǒng)，所述策略標簽是以下標簽中 的一個或多個Parent, Self, Caller, Classloader， Common, Allocater， Boundary, Leakbot和Heap Analyzer; 其中當策略標簽為Self時，則推理引擎確定當前組件為負責組件； 當策略標簽為Parent時，則推理引擎確定創(chuàng)建該線程的父組件 為負責組件；當策略標簽為Caller時，則確定調(diào)用當前組件的組件為負責組件；當策略標簽為Classloader時，則推理引擎確定裝載當前組件的 系統(tǒng)組件為負責組件；當策略標簽為Common時，則推理引擎確定提供公共服務的組 件為負責組件；當策略標簽為Allocater時，則推理引擎確定與資源相關聯(lián)的分 配器為負責組件；當策略標簽為Boundary時，則推理引擎確定位于執(zhí)行堆棧中最上面的組件為負責組件。
18. 根據(jù)權利要求11或12的系統(tǒng)，其中推理引擎進一步判斷當前組件或關聯(lián)策略是否改變，如果是， 則推理引擎進一步確定與所述運行時事件相關聯(lián)的負責組件。
19. 根據(jù)權利要求11-18中任一個的系統(tǒng)，其中所述推理引擎進 一步更新統(tǒng)計池中負責組件的統(tǒng)計。
20. 根據(jù)權利要求11 - 19中任一個的系統(tǒng)，其中通過主動采樣 或由事件被動觸發(fā)而獲取事件。
全文摘要
本發(fā)明涉及將運行時事件與組件相關聯(lián)的方法和系統(tǒng)。本發(fā)明的方法包括獲取運行時事件；獲取當前運行環(huán)境的上下文并根據(jù)所述上下文確定當前組件；獲取當前組件的關聯(lián)策略并根據(jù)所述關聯(lián)策略確定與所述運行時事件相關聯(lián)的負責組件。本發(fā)明的一個目的是將運行時事件與組件相關聯(lián)。本發(fā)明的另一個目的是在有復雜的互依存關系的組件組成的系統(tǒng)中確定哪個組件實際消費了資源。
文檔編號G06F11/34GK101393535SQ20071015345
公開日2009年3月25日 申請日期2007年9月19日 優(yōu)先權日2007年9月19日
發(fā)明者B·哈格雷夫, B·特蕾西, D·伍德, 劉天成, 影 李, 李欣慧, 滕啟明, 杰 邱 申請人:國際商業(yè)機器公司