Thread Controller

Thread Controller 主要接收所有傳入 Thread Manager Unit 對於 threads 運作的相關訊 號，並產生相對應的控制訊號到 Thread Queue、Thread Control Block 或其他內部元件。

Thread Controller 的工作包含管理 new thread 產生時所需要的初始化資訊、管理 thread 終止執行、處理同步機制的電路被啟動時，產生訊號到 Thread Queue 與 Thread Control Block 修改某個 thread 的狀態、當 Thread Controller 執行 context-switching 時也會修改相 關訊號到 Bytecode Execution Engine 各元件切換到 next ready thread 的執行資訊。圖 44 說明 Thread Controller 的狀態圖。由這些狀態來控制單一 JAIP 處理器內 threads 的操作，

每個狀態說明如下：

圖 44 The state diagram of Thread Controller

56

 Idle：

在 Idle 狀態時，表示此 JAIP 處理器底下只有一個 active thread，Thread Controller 將一直維持在此狀態，Thread Manager Unit 其他元件不會有任何動作，因此不會對 執行 Java 程式造成任何影響。直到 new thread 被產生使得 Thread Manager Unit 要 維護大於 2 個 active threads，此時才會轉換到下一個狀態。

 Prepare_next_TCB_info：

Thread Bytecode Execution Engine

rdyTH_

TOS_A mthd_id jpc vp sp

prevTH

這個狀態主要功用是從 Thread Control Block 讀取 next ready thread 的執行資

訊，以圖 45為例，透過 TH_data_out 把這些執行資訊依序傳到 Execute stage 的一

組 internal registers rdyTH_xxx (如圖 45的 R1 區塊)，其中 Miscellaneous Controller 代表修改 R1、R2、P1 這些區塊的 internal registers 相關電路。我們使用一個 on-chip memory 來實作 Thread Control Block，由於 on-chip memory 的 data ports 限制並且每

57

個 thread 的執行資訊皆由多個 32-bits special-propose registers 組成，所以任何一個 ready thread 的執行資訊從 Thread Control Block 讀取到 Execution Engine 的 internal registers 必須花 8 clocks。之後便拉起 Thread Controller 內部信號 TCB_rd_cmplt (圖 44)進入下個狀態。

 Check_Timeout：

主要用來檢查 current thread 在此回合剩下多少可使用的 time slice，這個狀態下 Thread Controller 會持續讀取 Counter Unit 的輸出並且會遇到 3 種情形：(1)如果 current thread 在此回合執行時間已經大於或等於我們設定的 time slice 數值，而且 Fetch Stage 解析出來的 bytecode 不是複雜指令，則 Thread Controller 發送控制訊號 給 Bytecode Execution Engine 記錄 current thread 目前執行到哪個 method (e.g. class ID、method ID)的哪一段指令(Java program counter)，以及記錄 stack frames 狀態(e.g.

stack pointer、variable pointer) (2)如果 current thread 在還沒執行到一個時間片段時已 經先發出 thread 終止的訊號，Thread Controller 直接把內部信號 timeout (圖 44)設成 1，進入下個狀態 (3)如果 current thread 執行 monitorenter 指令並且由 Data Coherence Controller 回傳的訊息表示取得 lock object 失敗，此時 Thread Controller 把內部信號 timeout (圖 44)設成 1。當目前狀態為 Check_Timeout 並且 timeout=1 的時候，Thread Controller 把 current thread 標記為 waiting state，最後進入下個狀態。

如果 current thread 此次使用的執行時間已經大於或等於我們設定的 time slice 參數，在這個時間點 Decode Stage 以及 Execute Stage 可能尚存有正在解碼或執行的 j_code。因此為了讓 thread 切換上更為簡便以及簡化所要記錄執行資訊的電路，在 執行到達一個時間片段時，並不會清除目前已存在於 Decode Stage 以及 Execute Stage 所要執行的 j_code，而是等待這 2 個 stage 的指令執行完畢之後，Thread Controller 內部信號 timeout=1，到下一個狀態再執行 context-switching。如此一來便 可降低管理 threads 的資源。

58

Interleaving

(from Bytecode Execution Engine)

runtime_SD

restore_SD

runtime_LD

(from Stack Manager, DDR memory)

bak_LD

(to Stack Manager, DDR memory)

(to Bytecode Execution Engine)

圖 46 Ping-pong Java stack memory 控制示意圖

 ContextSwitch：

首先將 ready thread 的 current class ID 與 method ID 將傳入 Method Area Manager (圖 8) 並且把 Method Area Manager 的內部訊號 ClsLoading_stall 設定為 1，此時便 暫 停 Bytecode Execution Engine 執 行 ， 啟 動 這 兩 個 電 路 載 入 對 應 的 method bytecode，還原 ready thread 上次執行的環境；當 Method Area Manager 完成工作後，

此時 ClsLoading_stall 等於 0，Thread Controller 必須切換 Bytecode Execution Engine 讀取 thread 執行資訊的來源。以圖 45為例，ready thread 的執行資訊此時儲存在 R1 區塊，而 Bytecode Execution Engine 執行指令時預設參考 R2 區塊的內容，也就是 current thread 的執行資訊。此時將 R1 區塊所有 internal registers 內容複製到 R2，同 時 R2 區塊的內容複製到 P1 區塊，此時也會改變 Ping-pong Java stack (圖 46)的內部 訊號 runtime_stack 的數值，來回切換 Bytecode Execution Engine 執行指令時使用的 interleaving stack memory。故 current thread 與 next ready thread 的 stack frames 切換 也只需要 1 clock 即可完成。

在這個狀態下當 Method Area Manager 的 ClsLoading_stall 等於 0，如果 Thread Manager Unit 維護的 thread 數量小於或等於 1，則下個狀態為 Idle；否則再細分以 下 2 個情況：如果 thread_terminate (圖 44)等於 1，這表示 previous thread 已經終止

59

執 行 ， 不 需 要 備 份 previous thread 執 行 資 訊 與 stack frames ， 故 下 個 狀 態 為 AllThreadsWait；否則需要備份 previous thread 的執行資訊與 stack frames，所以下 個狀態為 Backup_previous_TCBinfo。

 Backup_previous_TCBinfo：

這個狀態主要功用是把 previous thread 的執行資訊更新到 Thread Control Block 對應的位置，以圖 45 的 P1 區塊為例，Thread Controller 透過 TH_data_in、

TCB_wr_addr 把這些執行資訊依序寫到 Thread Control Block 對應的位置。同樣把 任何一個 thread 的執行資訊全部寫回去 Thread Control Block 必須花 8 clocks。之後 便拉起 Thread Controller 內部信號 TCB_wr_cmplt 進入下個狀態。

 Backup_Previous_Stack：

由於在先前執行 context-switching 時 JAIP 會將 Ping-pong Java stack 中所使用的 stack memory 切換到另一組 stack memory，此時 previous thread 所操作的 stack frames 還保留在 Ping-pong Java stack 中(圖 46)。為了降低在 JAIP 內部管理 stack frames 所 耗費之成本，在此狀態下 Thread Controller 觸發 Stack Manager，將 previous thread 的 stack frames 備份到 DDR-SDRAM 特定位置。由於 JAIP 處理器的是採用 Two-level Java Runtime Stack [3]的設計，主要是由 2 塊 Dual-Port on-chip memories 所組成，所 以若 Stack Manager 完整的將整個 stack frames 複製到 DDR-SDRAM 上則傳輸作業 時間會被拉長，因此 Stack Manager 會參考 previous thread 的 stack pointer (如圖 45 的 prevTH_sp)來做為傳輸長度，因為在執行時 stack memory 真正有用到的範圍也只 是從 0 到 Stack pointer 這個位址，Stack Manager 只傳輸有使用的部分，藉以降低傳 輸 stack frames 的時間。Stack Manager 完成 stack frames 備份的工作後觸發 stack_rw_cmplt 到 Thread Controller 改變狀態到 AllThreadsWait。

 AllThreadsWait：

多核心 JAIP 處理器環境下，考慮所有 threads 在某個時間內要取得某個 lock object，則有可能某個 JAIP 處理器底下 current thread 執行 monitorenter 取得 lock object 失敗並且同一個處理器底下所有其他 threads 已經先進入 waiting state，意即

60

這個 JAIP 處理器的 ready thread 數量等於 0，此時勢必由其他 JAIP 處理器的 current thread 把 lock object 權限轉移給這個 JAIP 處理器的某個 thread 恢復成為 ready state。

這個狀態主要用來檢查(1)Thread Manager Unit 的是否存在 2 個以上 ready threads 或 者(2)ready thread 數量等於 1 但是 current thread 取得 lock object 失敗。當這兩個條 件都不成立時，Thread Controller 的狀態會停留在 AllThreadsWait，因為此時 Thread Queue 不存在任何 ready thread ID 可以讓 Thread Controller 切換到下一個 thread 執 行 指 令 ； 如 果 上 述 兩 個 條 件 中 至 少 一 個 成 立 ， 則 Thread Controller 的 Ld_rdyTH_TCB=1 (圖 42)，到 Thread Queue 抓取 ready thread ID，利用這個 thread ID 到 Thread Control Block 讀取這個 ready thread 的 stack pointer。最後 Thread Controller 狀態切換到 Prepare_Next_Stack。

 Prepare_Next_Stack：

在此狀態 Stack Manager 會開始將此 ready thread 原本存放在 DDR-SDRAM 中 的 stack frames 傳輸到 JAIP 處理器並寫入到 Ping-pong Java stack 中目前由 Stack Manager 控制的 stack memory。與備份時相同，為了減短傳輸時間以降低對於正常 執行的影響。在上個狀態就已取出此 ready thread 的 stack pointer 作為傳輸長度。在 context-switching 被執行前先把 ready thread 的 stack frames 準備好，而當要進行 context-switching 時，Thread Controller 只需切換 Bytecode Execution Engine 所使用 的 stack memory 即可。利用此種作法，Thread Manager Unit 也不需要用額外硬體資 源維護每個 thread 的 stack frames。同樣地 Stack Manager 完成 stack frames 載入的 工作後觸發 stack_rw_cmplt 到 Thread Controller 改變狀態到 Prepare_next_TCB_info。