多執行緒Java處理器設計

國

立

交

通

大

學

資訊科學與工程研究所

碩

士

論

文

多執行緒 Java 處理器設計

Design of the Multithreading Architecture for a Java Processor

研 究 生：吳宗漢

指導教授：蔡淳仁 教授

多執行緒 Java 處理器設計

Design of the Multithreading Architecture for a Java Processor

研 究 生：吳宗漢 Student：Tsung-Han Wu

指導教授：蔡淳仁 Advisor：Chun-Jen Tsai

國 立 交 通 大 學

資 訊 科 學 與 工 程 研 究 所

碩 士 論 文

Submitted to Institute of Computer Science and Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer Science

June 2014

Hsinchu, Taiwan, Republic of China

摘要

多執行緒在 Java 平台內是不可或缺的功能，例如 web-browser 內需要管理不同子視 窗的連線、或者檔案下載軟體可能使用多個執行緒同時載入同個檔案內不同的 data block。在本論文中我們將以 Java Application IP (JAIP)為基礎，提出一個 Multicore multithreaded Java processor Architecture，藉由同時執行多個 Java 處理器並且每個 Java 處理用上啟用 temporal multithreading 機制，達到每個處理器資源使用最佳化並且能容納 更多執行緒，為了在我們提出的設計之中解決 thread 的分配與同步問題，我們也提出新 架構用以協同每個 Java 處理器運作並且處理程式執行的一致性。此架構在 Xilinx ML-605 FPGA 平台上驗證。實驗結果顯示，我們提出的架構比單一 Java 處理器啟用 temporal multithreading 的執行效能有顯著的提升，並且將大幅縮減電路資源使用。

誌謝

目錄

摘要 ... I

誌謝 ... II

目錄 ... III

圖目錄 ... V

表目錄 ... VII

第一章 前言 ... 1

第二章 相關研究 ... 6

2.1. Previous Work on JAIP ... 6

2.2. 多執行緒與同步處理相關研究 ... 8

第三章 Multicore Multithreading Java 處理器架構... 13

3.1. Hardware Native Interface ... 18

3.2. Synchronization Operation ... 21

3.3. Inter-Core Communication Unit (ICCU) ... 27

3.4. Data Coherence Controller ... 32

3.4.1. Mutex Controller ... 34

3.4.2. Thread Assignment Controller ... 37 III

3.4.3. Lock Object Accessing Controller ... 41

第四章 Java 處理器 Temporal Multithreading 架構 ... 53

4.1. Thread Controller ... 56

4.2. Thread Control Block ... 61

4.3. Thread Queue ... 64

第五章 實驗結果 ... 68

5.2.3. Thread Manager Unit 效能分析 ... 74

5.2.4. Data Coherence Controller 效能分析 ... 77

第六章 結論與未來展望 ... 80

參考文獻 ... 81

圖目錄

圖 1 傳統 Java 執行環境 ... 3

圖 2 The block diagram of JAIP ... 6

圖 3 The block diagram of 2-level stack memory ... 7

圖 4 The block diagram of Ping-Pong Java stack ... 8

圖 5 The block diagram of KOMODO microcontroller ... 9

圖 6 The block diagram of jamuth ... 10

圖 7 CMP system based on JOP ... 12

圖 8. The block diagram of JAIP ... 13

圖 9. Synchronized method 與 Synchronized Statement 範例 ... 15

圖 10. 產生 thread 並且同時呼叫 Synchronized 程式區段的範例 ... 16

圖 11 Data Coherence Controller 與各個 JAIP 處理器的關係圖 ... 17

圖 12 JAIP 調用的 3 種介面 ... 18

圖 13 在 DSRU 中呼叫 Hardware Native Interface 的 state diagram ... 19

圖 14 method info list 訪問過程與 method info 格式 ... 20

圖 15 Fetch stage 解析複雜指令示意圖 ... 22

圖 16 在 DSRU 中呼叫 synchronized method 的流程 ... 24

圖 17 return frame 格式 ... 25

圖 18 The state diagram of Method Area Controller ... 27

圖 19 The block diagram of Inter-Core Communication Unit ... 27

圖 20 DCC2JAIP_response_msg 的格式 ... 29

圖 21 ICCU 將 response status 回傳給處理器之示意圖 ... 30

圖 22.ICCU 將 response status 回傳給處理器之示意圖 ... 31

圖 23 The block diagram of Data Coherence Controller ... 32

圖 24 The state diagram of Synchronized Manager in [1] ... 34

圖 25 The block diagram of Mutex Controller ... 34

圖 26 The state diagram of Mutex Controller ... 35

圖 27 JAIP information table ... 37

圖 28 Thread assignment controller 工作流程，範例 1 ... 38

圖 29 Thread assignment controller 工作流程，範例 2 ... 40

圖 30 Thread assignment controller 工作流程，範例 3 ... 41

圖 31 The block diagram of Lock Object Accessing Controller ... 42

圖 32 The format of (a) waiting thread entry and (b) lock object entry ... 43

圖 33 waiting thread entry 與 lock object entry 與關係圖 ... 44

圖 34 LOAC 內部逐一比對 lock object 流程圖 ... 45

圖 35 LOAC 內部成功取得 lock object 之流程圖 ... 46

圖 36 範例：在 Waiting Thread Table 產生一條 Object L0 的 linked list N0 ... 47 V

圖 37 查詢 Waiting Thread Table 內特定 lock object 的 linked list ... 48

圖 38 範例：在 linked list N0 內新增一個 tail node... 49

圖 39 lock 擁有者釋放 lock object 流程圖，J1 表示流程連接點，請參考圖 34 ... 50

圖 40 範例：在 Waiting Thread Table 的 linked list N0 內移除 head node... 51

圖 41 範例：在 Waiting Thread Table 移除 Object L0 與 thread t2 ... 52

圖 42 The block diagram of Thread Manager Unit ... 53

圖 43 切換 thread 流程 ... 54

圖 44 The state diagram of Thread Controller... 56

圖 45 執行 context-switching 時，threads 執行資訊切換示意圖 ... 57

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

圖 47 每個 Thread 儲存在 Thread Controller Block 內的執行資訊... 62

圖 48 Thread Queue 操作示意圖 ... 66

圖 49 JAIP 與 CVM 在 temporal multithreading 機制下的效能比較結果 ... 71

圖 50 不同 time slice 參數對於 benchmark program 執行分數的影響 ... 76

圖 51 Jembench Suite 的 parallel benchmark program 計算執行時間之示意圖 ... 77

表目錄

表 1 ICCU 支援的 request type ... 28

表 2 ICCU 支援的 response type ... 28

表 3 Resource Utilization (a)proposed JAIP (b) proposed DCC ... 68

表 4 Resource Utilization 比較表 ... 69

表 5 多核心 JAIP 處理器執行效能 (未啟用 temporal multithreading) ... 72

表 6 多核心 JAIP 處理器執行效能 (已啟用 temporal multithreading) ... 73

表 7 N-Queens 程式執行效能 (使用 2 個 lock objects) ... 74

表 8 不同 benchmark programs 下 context-switching 執行時間 ... 75

表 9 產生 new thread 所需的執行時間 ... 78

表 10 current thread 取得 lock object 所需的執行時間 ... 78

表 11 current thread 釋放 lock object 所需的執行時間 ... 79

第一章 前言

1.1. 研究動機

近年來 Java 因為其可移植至不同作業系統與處理器的特性，而成為嵌入式平 台的主流開發語言之一，其中一個知名範例是 Android 作業系統，其 Application Framework 的部分主要使用 Apache Harmony 這組 library 開發。Java 也提供許多 API (Application Programming Interface)以支援軟體專案的開發，其中一項重要應用 為提供程式介面以支援多個 thread 並行執行，Java VM 規格書與 API 皆說明 thread 管理時使用的語法以及造成的效果，然而許多 multithreading 相關操作必須仰賴底 層 硬 體架 構或 作業 系 統完 成 thread 的執行 資訊維護，因此設一 個有效率的 multithreading 管理機制勢必為一項重要議題。

針對 Java multithreading 的設計，可簡單區分為由軟體或硬體支援：由軟體所 支援的 Java 執行環境包括 Sun Microsystems 提出的 Java VM，以及可在嵌入式平 台上執行的 CVM，對於 thread 的管理與同步機制運作大多透過直接執行 Java Bytecode 指令以及透過 native methods 來支援，而 Java 規格將 native method 實作 細節留給底層作業系統決定，此種做法有兩項限制：(1)Time slice 數值通常以 millisecond 為計算單位，例如 Unix-like kernel 的 time slice 大約在 10 milliseconds， 此項限制在某些領域會造成嚴重問題，例如可穿戴式電腦，當使用者有任何動作 時，裝置的處理器必須能快速取得個別 sensor 收集到的資料以減少回應時間 (2)Context-switching 執行時間，thread context 內容取決於處理器與作業系統架構。 一般 RISC core 處理器底下每一個 thread context 包含一組 CPU registers、program counter 與 被分配到 的 main memory space； Java thread 的 context 除了少數 special-purpose registers 之外還包含 stack frames，當執行 context-switching 時由作 業系統觸發 interrupt 訊號到 interrupt service routine 切換 current thread 與 next ready thread 的 context，此過程至少需要 500 個 clock cycles 以上。

由硬體所支援的 Java 處理器環境包括 Pico-Java、KOMODO、JOP 等，主要特 1

性為不需要底層作業系統支援、直接由電路管理多個 Java thread 的 context，這表 示開發者可以透過各種方式達到較少的 time slice 與 context-switching 執行時間。 由於 Java thread context 的大小比一般 RISC core 的 thread context 高，因此設計一 個節省硬體資源的 thread 管理方法是我們的研究重點。

近年來多核心處理器架構在嵌入式系統應用上日漸廣泛，在多核心 Java 處理 器方面，雖然 JOP[24][28]已經有提出多核心處理器的研究但是仍然有效能的問 題。為了實作多核心 Java 處理器架構並且每個處理器支援多個 threads，在 Java 執行環境中必須確認應用程式執行結果的一致性，設計有效率的同步機制協同多 個 threads 並行執行也是我們的研究重點。

1.2. 研究目的與貢獻

本篇論文以一個異質雙核心 Java Application IP (JAIP)應用處理器[1][2]為基 礎，提出一個 Multicore Multithreading Java Processors 架構。JAIP 為一個具高度可 移植性的 Java IP core，負責處理所有 Java Bytecode 的執行，並且支援字串處理與 Temporal Multithreading 機制，為了讓多核心 JAIP 環境彼此間能夠正常執行，在[1] 的研究中提出 Multi-core Coordinator 負責處理 thread synchronization 與 cache coherence 問題。

先前 JAIP 的 Temporal Multithreading 管理電路之中使用大量 registers 暫存 thread context 之中所有的 special-purpose registers 因此造成硬體資源使用量大增。 另 外 在 原 先 多 核 心 JAIP 處 理 器 架 構 下 [1] 單 一 JAIP 內 部 不 存 在 Temporal Multithreading 管理電路，意即單一 JAIP 只能容納一個 thread，假設其中一個 JAIP 的 current thread 取得 lock object 失敗時，Multi-core Coordinator 的實作上只需要讓 這個 thread 暫停執行指令，因為單一個 JAIP 內只有一個 active thread 所以無法切 換到下一個 ready thread 執行，導致這個 JAIP 閒置的情形發生。

為了讓 Java 支援底層硬體操作，[2]提出一個讓 JAIP 的 Bytecode Execution Engine 直接透過 Dynamic Resolution 機制來操控硬體設備或電路之介面─Hardware

Native Interface。Java 程式語言可以透過這個介面觸發 Temporal Multithreading 機 制並執行 thread 相關管理工作。

本論文研究重點在於提出方法以支援多核心 JAIP 處理器環境同時整合 Temporal Multithreading 與 Hardware Native Interface 機制，為了達到此目的，我們 也提出方法改進 Multi-core Coordinator 之中分配 thread 與同步功能，並且更改其名 稱為 Data Coherence Controller，使單一 JAIP 處理器底下能容納更多 threads，並且 最佳化 thread 管理的電路資源使用。

1.3. Java 執行環境

Java 執行環境是由 Java VM 與一組標準類別庫所組成，在 Sun Microsystem 所 推出的 Java Platform, Micro Edition 應用範圍涵蓋工業控制到行動裝置等。此外 Java Platform， Micro Edition 還區分為兩類。用於小型行動裝置或用以實現較多功能的 設備，如智慧型手機或電視機上盒等。把運算功能有限、電力有限的小型行動嵌 入式裝置定義在 Connected Limited Device Configuration(CLDC)[4]規格之中，另外 功能較為強大的裝置則規範為 Connected Device Configuration(CDC)[5]規格。

Class Loader Runtime data Method Area Heap Java Stack Program Counter Native Method Stacks Execution Engine

Native Method Interface Runtime

Constant Pool

Java Virtual Machine

Host Operating System

Class files

圖 1 傳統 Java 執行環境 3

傳統 Java 執行環境(如圖 1)包含軟體 Java VM，它依賴完整的作業系統去執行 Java 應用程式。Java VM 中有三個重要元件，Class Loader、Runtime Data 與 Execution Engine[6]。Class Loader 此元件負責載入指定的類別(Class)或介面(Interface)。 Runtime Data 為提供 Java VM 在執行程式時所需資料，包括運算堆疊、執行方法 等。Execution Engine 負責去執行所載入方法的指令。

雖然 Java VM 在實作時可以只用軟體直譯器（Interpreter）來執行 Java 程式， 像是 Sun 的 CVM[8]與 KVM[9]就是在嵌入式裝置中利用軟體實作 Java VM 的直譯 器[10]，但是直譯器在執行 Java 程式時相當沒有效率。因此大部份 Java 執行環境 會使用加速技巧優化執行效率。有許多解決方法可以改善在嵌入式環境下 Java 應 用程式的效能。這些解決方法提供 Java 執行時空間或時間的改善。大致上可分為 三類：單純以軟體加速的編譯器(例如：Just-in-Time 編譯器[7])、協同式的 Java co-processor，例如 ARM Jazelle[11]與 Nazomi JSTAR[12]、standalone Java processor，例如 Sun picoJava [13][14][21]及 aJile aJ-102 [15][16]。

利用 Just-in-Time 編譯器的技術藉由執行時期將部分 Java bytecode 轉換成 native code[17]並暫存於系統之中，可顯著的提高執行效率，但 Just-in-Time 需要額 外的記憶體空間和在 Class 被載入時所附加額外編譯時間。因此在對記憶體資源較 為嚴格要求的嵌入式應用設計較不適合。另一提高 Java 執行效率的方法為協同式 的 Java co-processor。像是具備內嵌轉譯器（Embedded Java Translator）的 ARM Jazelle 及 Nazomi JSTAR，其具備可以切換執行 Java bytecode 的處理器設計、或像 是 standalone Java processor：Sun picoJava、Komodo[16]及 JOP [18]都可單獨執行 Java 程式。這些處理器皆是依照 Java VM 的堆疊機制所設計，因此其執行的效率 會比一般處理器所運行的 Java 直譯器來的高。

JAIP 採用易於與其他處理器整合的弱協同式設計(weakly-coupled co-design)， 只要 RISC 處理器支援 interrupt-driven 之 communication 便可與 JAIP 整合。JAIP 可以獨力完成幾乎所有的 Java 程式計算，只有程式需要低階 I/O 裝置控制例如 RS-232 controller，或從 Compact Flash Card 載入 class file 並且解析，才會需要使

用 RISC 處理器計算。

1.4. 論文架構

本論文一共分為六章，本章是一個概略性的導論，說明背景、動機以及論文 大綱；第二章為相關研究，會先介紹在本論文中作為設計基礎的 JAIP 先前研究， 並接著介紹與 Java multithreading 機制相關研究；第三章與第四章說明多核心 JAIP 處理器上整合 Temporal Multithreading 系統架構與 Data Coherence Controller 的設計 細節；第五章分析實驗結果；最後第六章則是本篇論文的結論及未來可能的研究 方向。

第二章 相關研究

此章節先說明 Java 執行環境並呈現我們設計時作為基礎所使用的嵌入式異質雙核 心 Java 處理器。之後會介紹不同 multithreading 機制的相關研究。

RISC core

Java Application IP (JAIP)

Object Heap Controller

Mailbox

Bytecode execution engine Ping-Pong Java Stack

Thread Manager Unit Method Area Manager Method Image Circular Buffer Symbol Table Circular Buffer DSRU Class Reference Table CF card (Application classes) CF card controller Data Coherence Controller

External memory controller

DDR3-SDRAM interrupt System Bus Inter-Core Communication Unit class image pool stack backup space RSIC core ISR object heap space Hardware Native Interface

圖 2 The block diagram of JAIP

2.1. Previous Work on JAIP

本論文所採用的 JAIP 處理器架構[26]如圖 2 所示，包含 Bytecode Execution

Engine(BEE)負責直接執行 Java bytecode 指令，部分指令運算結果、local variables 以及 return frame 被暫存到 Ping-Pong Java Stack；而 object fields 與 class fields 則被暫存到 Object Heap Space 與 2-way Set Associative Heap Cache Controller。根據 Java instruction set 定義，某些 bytecode 指令其後的 operand bytes 用來指向 class file 的 constant pool 特定位 址，此時便需要 Dynamic Symbol Resolution Unit(DSRU)作符號解析的工作，每次解析到 的新的 Class 則由 Method Area Manager 底下的 Class Symbol Table Controller (CST Controller)與 Method Area Controller (MA Controller)負責載入 constant pool data 與 method

bytecode，以及 DSRU 執行時會用到的 field info 與 method info 也將被寫入到 Cross Reference Table。另一個核心為 RISC-core，主要負責 class loading and parsing 和 serial port I/O 管理等工作。

BEE 是一個獨立的模組。它可以整合到任何的 host 端處理器，只要 host 端支援 interrupt-driven 之 inter-processor communication 機制。BEE 是一個 4-stage pipeline，包括 translate、fetch、decode 及 execution stages。Translate stage 透過 jpc 將 Method Area 內的 Java Bytecode 讀出，每次從 Method Image Circular Buffer 讀出兩個 byte 資料，每個 opcode 皆會經過 translation ROM 轉換為一對 j-code info.。j-code info.被送進 fetch stage 後，被 分類成為 simple 及 complex 兩種類型 bytecode，若為 simple bytecode，會被轉換成一個 BEE 指令─j-code，兩個無 hazard 之 jocde 可以被 double-issued；若為 complex bytecode， 會被轉換為一組 j-code-pair sequence。每個 j-code pair 會經由後面的 decode stage 和 execution stage 執行。為了讓指令平行度增加，[3]提出了 2-level stack memory 架構(圖 3)， 為了支援不同 thread 之間快速切換 stack frames，[1]擴充 2-level stack memory 實作 Ping-Pong Java Stack(圖 4)。

Customized 4-port memory LV 0 LV 1 LV 2 LV 3 Java Stack dual-port BRAM dual-port BRAM RA1 RA2 WA1 WA2 RD1 RD2 WD1 WD2 TOS_A TOS_B TOS_C

圖 3 The block diagram of 2-level stack memory

Ping-pong stack memory LV 0 LV 1 LV 2 LV 3 Java Stack 0 dual-port BRAM dual-port BRAM Java Stack 1 dual-port BRAM dual-port BRAM RA1 RA2 WA1 WA2 TSA RD1 RD2 WD1 WD2 BD PD TOS_A TOS_B TOS_C DDR-SDRAM

圖 4 The block diagram of Ping-Pong Java stack

DSRU 負責在 runtime 時解析 Symbol Table Circular Buffer 中每個 entry 的資訊、協 助觸發額外加速電路[2]與 class loading 請求、傳遞 class ID 和 method ID 到 CST Controller 和 MA Controller 中。Symbol table 在一般程式語言中，是一個專門儲存 identifier 資訊之 資料結構，可供 compiler、interpreter 或 linker 查詢變數型態、scope 或函式進入點。在 我們的 JAIP 平台中，Symbol Table Circular Buffer 存放著 ldc bytecode 所用的 constant 資訊、new bytecode 需要的 class ID、field 操作和 invocation 時都需要的 Cross Reference Table 之 entry reference。

Cross referece table 內的結構則是由一個 entry 表示的 field info.，或是由 2 個 entries 組成的 method info。在 BEE 遇到 field 操作、load constant 或 method invocation 類型的 bytecode 指令時，會啟動 DSRU 來解析 Symbol Table Circular Buffer 與 Cross Reference Table 之內容。

2.2. 多執行緒與同步處理相關研究

其他 Multithreaded Java processors 相關研究中，[22]提出的 Java 加速電路包含 CPU 8

portion 與一個 thread lifetime unit 電路負責 active threads 管理與排班機制，並使用一個 timer 倒數紀錄 current thread 的執行時間，一旦 timer 的值小於等於 0，thread lifetime unit 會觸發訊號給 CPU portion，此時 current thread 在 CPU portion 下的 register sets(包含 current thread 的 operand stack values 與)將被清除並且備份到 memory，並且載入 Java Virtual Machine 到 CPU portion 執行 thread 排班。

圖 5 The block diagram of KOMODO microcontroller

KOMODO[16]使用 4 個 thread slots 儲存每個 thread 執行資訊包括 program counter、 Instruction window、一組 stack registers (圖 5)，每次從 Memory Interface 依序載入一組 4-byte instruction package 到 Intrsuction windows，此時這 4 個 instruction windows 可能儲 存 0 到 4 個 opcode，接著由 Priority Manager 檢查每個 thread 的 characteristic value[19] 判斷哪個 thread 對應的 instruction window 優先被執行並傳到 MEM 或 ALU。其中 characteristic value 為 Priority Manager 的 internal register 並且可視為 thread state，包含這 個 thread 是否在等待 Atomic lock、以及這個 thread 的指令是否在執行 external memory

相關操作。在 KOMODO 處理器中，I/O 操作完成時(e.g. 使用外部 timer 計算每個 task 的執行時間、memory-accessing)會傳 external signal 並且觸發 Signal Unit，使 Priority Manager 修改 characteristic value。如果在此架構下要擴張 thread 的數量則容易造成電路 資源使用過高。

Jamuth[20]以 KOMODO 為基礎，並且提出一些改進的設計(圖 6)例如：所有 hardware threads 共享一個 2k-entry stack cache、採用 4-KB direct-mapped instruction cache 存放部 分 method bytecode 以減少載入指令的 latency。但是 2k-entry stack cache 被切成 4 個部分 分別存放 4 個 threads 的 stack frames，此作法同時只能有一個 thread 執行指令並且存取 stack cache 而其他 threads 只能將個別 stack frames 搬入 stack cache 或搬出到 external memory。此作法同樣會增加電路的複雜度。Jamuth 皆以 complex trap routines 實作 thread 同步機制例如 Java 指令 monitorenter[6]因此會有比較高的 synchronization overhead。

圖 6 The block diagram of jamuth

aJile aJ-102[16]包含一個 execution unit、Unified I-cache 與 D-cache 與 32KB microcode RAM，aJ-200 以 extended bytecode instruction 方式支援直接執行 thread 管理與同步功能， 此作法也使用極少的硬體成本。aJ-200 官方文件指出 context-switching overhead 少於 1

microsecond。另外 aJ-200 提出 MJM (multiple JVM manager)功能，可支援 2 個 JVM 同 步執行 2 個獨立的 Java 應用程式，每個 JVM 被分配一個內部 timer 用來計算 current thread 的 time slice，MJM 底下可以個別設定每個 JVM 的 thread 排班演算法。

PicoJava-II [13][21]之中每個 thread context 包括一組 registers，用來記錄以下資訊： 紀錄 current method 的 base address、stack 頂端元素的位置、local varaible 起始位置、每 個 thread 被分配到的 external memory address range、constant pool 的 base address、program status register 、 program counter 等 。 picoJava 採 用 interrupt 的 方 式 執 行 額 外 context-switching code，切換 current thread 與 next ready thread 的 context，並且需要額外 軟體程式支援 thread scheduling，此做法會導致 context-switching overhead 增加。

picoJava 支援 hardware synchronization 機制，同時可執行最多 2 個 lock object 權限 取得或釋放的工作，在執行同步機制操作時會使用特定用途的 registers 暫存 lock object 的參考位置、目前是否存在其他 waiting thread、以及 lock object 擁有者重複取得 lock 的 次數。在 memory 之中每個 object header 皆包含 lock bit 用來判斷每個 object 是否已被某 個 thread 取得權限。[21]提出在 Java object 內維護一個 pointer 指向自行定義 Java class 資料結構，用以儲存每個 lock object 相關 waiting threads。此作法雖然使用極少的硬體 成本，但是執行同步操作時維護 waiting threads 會增加 object fields 存取次數，執行時間 將會增加。

在多核心執行環境下，Java Optimized Processor(JOP) [24][28]使用最多 8 核心 Java 處理器加上 shared memory[23][27](圖 7)。而每一個處理器上都有一組 stack cache 與 method cache，分別使用 on-chip memory 實作並且自行定義 microcode 執行堆疊操作。 當開始執行 Java 程式時，多核心 JOP 環境的其中一個處理器(假設為 JOP0)負責初始化 整個系統的工作，完成初始化之後開始執行 bytecode 指令，每個處理器會被分配一個 ID number，當系統有新的 thread 被產生，一律由第一個處理器(JOP0)分配 ID number 與 threads 給其他處理器，在此架構下不支援 thread migration。每個處理器輪替執行不同 threads 並且以內部 timer 檢查執行時間，當每個 JOP 處理器需要執行 context-switching 時，藉由 local timer interrupt 觸發 thread scheduler，thread scheduler 由 Java 程式實作並

且執行 thread scheduling 與 2 個 threads 的 stack frames 切換，由於 JOP 以 on-chip memory 實作 stack cache 因此 threads 使用的 stack frames 數量將決定資料來回搬移到 main memory 的時間，也影響 context-switching 整體時間。Hardware synchronization 方面， Arbiter 依序處理每個 JOP 處理器對 shared memory 的 read/write operation，Synchronization unit 只包含一個 global lock，所有 threads 進入 synchronized method 或 synchronized code block 之前必須先到此模組取得 global lock，當每個 JOP 處理器取得 lock 失敗之後則必 須等待，此時在此 JOP 處理器下無法切換到另一個 ready thread 繼續執行 bytecode。

JOP_1 Stack cache Method cache JOP_0 Stack cache Method cache JOP_N Stack cache Method cache Arbiter

…

圖 7 CMP system based on JOP

第三章 Multicore Multithreading Java 處理器架構

Java 語言定義 java.lang.Thread class 使得任何 Java 平台上可以管理多個 threads 同步 執行應用程式。任何 Java 平台開始執行應用程式前會先取得 main method 相關資訊，依 照不同平台實作方式會先解析必要的 Java Class 並且載入到 method area、初始化 heap 與 program counter[6]、接著產生 main thread 且開始執行 main method 的 Bytecode 指令， 如果 main thread 執行過程中產生多個 threads，此時依照不同 Java 平台實作決定以下事 項：(1)多核心 Java 處理器環境下該如何記錄並且分配 new thread 的執行資訊到哪一個 處理器 (2)單一處理器下，當 current thread 結束執行或者取得 lock object 失敗時，如何 切換到另一個 thread 執行 (3)多核心 Java 環境下，2 個不同處理器的 threads 同時修改 shared data 時造成的 race condition 問題 (4)當某個 thread 釋放 lock object 之後，必須決 定下個取得此 lock object 的 waiting thread。

RISC core

Java Application IP (JAIP)

Object Heap Controller

Mailbox

Bytecode execution engine Ping-Pong Java Stack

Thread Manager Unit Method Area Manager Method Image Circular Buffer Symbol Table Circular Buffer DSRU Class Reference Table CF card (Application classes) CF card controller Data Coherence Controller

External memory controller

DDR3-SDRAM interrupt System Bus Inter-Core Communication Unit class image pool stack backup space RSIC core ISR object heap space Hardware Native Interface

圖 8. The block diagram of JAIP

本章節我們將以先前 Java Application IP (JAIP) 的單核多執行緒架構 [1][2]為基 13

礎，介紹 Multicore multithreaded Java 處理器架構(單一 JAIP 核心架構，如圖 8)，藉由 多個 JAIP 處理器同時執行且每一個 JAIP 啟用 temporal multithreading 機制，達到多個 threads 真正同步執行並且能容納更多 threads。為了使我們提出的架構能順利執行，我們 將修改之前 Thread Manager Unit 對以下功能的實作。

1. Java 語言的 Thread class 提供 Thread.start() method 作為產生 new thread 的方式，當 current thread 呼叫 start method 時，Java VM 透過內部機制產生 new thread 的相關執 行資訊例如 stack pointer、program counter、current class ID/method ID 等，由 Java VM 決定何時要切換到這個 new thread 並且執行其第一個 method：Thread.run()，當每一 個 thread 在 run method 執行 return 指令時，表示這個 thread 結束執行。當 start method 被呼叫後，如何管理這些 threads 執行資訊?如何設計 context switch 機制抓取下個 ready thread?這些將留給個別 Java 平台實作。

2. Java VM 定義 monitor 來協調多個 threads 執行時遇到的同步問題，每一個 Object

只包含一個 lock，當多個 threads 要進入 critical section 之前，必須先從 monitor(Object) 取得 lock，此時必定只有一個 thread 成功取得 lock 且進入 critical section，而其他 threads 必須等待。當一個 thread 已取得 lock object 時可以在 critical section 內執行 程式，直到這個 lock object 被釋放且分配給這些 waiting threads 的其中一個，如果 不存在對應的 waiting threads 則該 lock 歸還給 monitor。

為解決同步執行問題，Java 語言提供 Synchronized 保留字，其使用方式如圖 9 與圖 10，修改 shared data (field shared1、shared2)的程式碼被放在 Synchronized statement 或 Synchronized method ， 一 旦 任 何 thread 要 更 改 shared data ， 都 必 須 呼 叫 Synchronized method A2、A3，或者執行 Synchronized(lock){ ... 這段程式。將圖 9 的 class B 編譯過後，method B2、B3 的 bytecode 會包含 monitorenter/monitorexit 指 令[6]，這兩個指令可被視為每段 critical section 的第一個與最後一個指令。以圖 10 為範例，假設 thread t1 呼叫 method B2 並且進入 critical section 之前，t1 的 Java stack 的 top element 會存放對應的 object reference (e.g.由前一個指令 push 到 stack 上)，接 著 t1 執行 critical section 的第一個指令 monitorenter，在 Java VM 內部取得 lock

object，如果 Java VM 決定將 lock 權限交給 t1，則 t1 才可以進入 critical section 往 下執行指令，否則必須暫停執行直到其他 thread 釋放 lock 並且將 lock 權限轉移給 t1。當 t1 離開 critical section 時，同樣在 Java stack 的 top element 會存放對應的 object reference，此時執行 monitorexit 指令以進行 lock 權限轉移或歸還的工作。

圖 9. Synchronized method 與 Synchronized Statement 範例

當 t1 取得 object A 或 B 的內部 lock ，此時 t1 有權限重複取得相同的 lock，Java VM 對每一個 Object 會維護一個內部 counter 記錄目前每個 lock 擁有者取得此 lock object 的次數，如果 lock object 的 counter=0 表示任意 threads 都有機會取得這個 lock object；如果 t1 多次重複取得 lock object，則 lock object 對應的 counter 會逐次累加， 這表示之後 t1 必須釋放相同的 lock object 達到相同次數後 (每釋放 1 次 lock object，counter 遞減一個單位)，直到 lock object 的 counter=0 才算是把 lock 真正釋 放並且把權限轉移給其他 waiting threads。monitorenter/monitorexit 被執行時，個別 Java 平台必須提供 monitor 相關實作機制、包括如何紀錄 waiting threads、ready threads、lock object 狀態 (e.g.目前 lock 擁有者、對應的 counter)、決定 thread 是否

成功取得 lock object、lock object 權限轉移或歸還。另外，圖 9 的 class A 編譯後， method A2、A3 的 bytecode 並不會包含 monitorenter / monitorexit 指令，這表示 synchronized method 相關實作由個別 Java 平台自行決定。

圖 10. 產生 thread 並且同時呼叫 Synchronized 程式區段的範例

上述功能在先前 Multi-core Coordinator[1]設計中僅適用於 temporal multithreading 機 制未被啟用的多核心 JAIP 處理器環境，每一個處理器只能容納一個 thread，此時當一個 thread 取得 lock object 失敗時，這個 thread 即暫停執行指令，因為 temporal multithreading 機制未啟用所以無法切換到下一個 ready thread 執行，導致 Bytecode Execution Engine 閒 置的情形發生。

在多核心 JAIP 處理器環境下如要啟用每一個 JAIP 的 temporal multithreading 機制， 16

我們將修改先前的設計並且更改其名稱為 Data Coherence Controller (圖 11)，當 Data Coherence Controller 收到來自 JAIP 處理器的 request 時：(1)先由 Mutex Controller (圖 25) 檢查 Data Coherence Controller 目前是否正在執行其他處理器的 request signal，確定每一 個 JAIP 的 request 都能正確地被執行 (2) Mutex Controller 會解碼 request signal 啟動不同 電路模組。若進來的 request 是要分配 new thread 到其他 JAIP，則啟動 Thread Assignment Controller (圖 28)；若進來的 request 是要取得/釋放 lock object，則我們提出 Lock Object Accessing Controller 的設計(圖 31)，可以檢查所有 threads 等待所有 lock objects 的狀態。

圖 11 Data Coherence Controller 與各個 JAIP 處理器的關係圖

為了使 Data Coherence Controller 能控制每個 JAIP 處理器底下的 Thread Manager Unit，我們也在每個 JAIP 處理器內提出 Inter-Core Communication Unit (圖 11，以下簡 稱 ICCU)的設計。同時為了使 ICCU 能正確執行，我們也將修改原本 JAIP 的 DRSU 與 Thread Manager Unit 部分元件例如：Thread Control Block、Thread Queue 與 Thread Controller，Hardware Native Interface 設計也將被整合到 JAIP。

本章節可大略分為二個部分；第一部分先說明單一 JAIP 處理器 thread 的新增分配 流程以及同步操作的設計，最後將會觸發 ICCU；第二部份再介紹 Data Coherence Controller 以及每個 JAIP 處理器底下的 ICCU 與 Thread Manager Unit 如何互相運作，以 維護 threads 執行資訊。

3.1. Hardware Native Interface

Java 平台的 native method 大多數以其他語言或組合語言的 library 實做，透過呼叫 這些 library 完成工作並且回傳數值。為了使 Java Thread Class 能正確地操作 ICCU、Thead Manager Unit 或者其他加速電路，在不修改原有 Java 應用程式情況下，我們加入 Hardware Native Interface[2]的設計，這個介面由 DSRU 觸發，使得 native method 的執行 介面達到一致性，如果開發者要為某一個 native method 新增一個等價電路時，便可以簡 單地連接 Hardware Native Interface 的輸出輸入訊號。

Dynamic Symbol Resolution Unit

Method Area Controller cls _ id m thd_i d Bytecode Execution Engine RISC-code Hardware Accelerator na ti ve _H W _I D na ti ve _H W _e n na ti ve _H W _c m pl t jav a_ b y teco d e int er rupt _f unc _D R int er rupt _r eq_D R int er rupt _c m pl t IPC Register file

PLB

(1) Bytecode Execution Engine (2) RISC-core (3) Hardware Accelerator

圖 12 說明 JAIP 處理器內 2 種 natvie method 的實作方式：其一是啟動 interrupt 通 知 RISC-core，RISC-core 提供對應的 native C function 來完成工作，執行過程中由 RISC-code 讀取 JAIP 的 stack memory 頂端 data words；第二種方式是 Hardware Native Interface，當 DSRU 解析過程中發現即將呼叫一個 native method，且該 native method ID

對應到某個 JAIP 處理器支援的 Hardware Accelerator，則啟動對應的電路、傳入 method 參數並執行工作、把回傳值寫到 stack memory 頂端，當其對應的電路工作結束時，發送 完成訊號到 DSRU，此時完成 native method invocation。此設計的好處是可降低 native method 執行時間。

圖 13 在 DSRU 中呼叫 Hardware Native Interface 的 state diagram

在我們的設計下當 current thread 呼叫 native method 會執行 invokevirtual、invokestatic 等指令 ，當 Decode Stage 解析發現要執行這些指令時便會啟動 Dynamic Symbol Resolution Unit(DSRU)，此時 DSRU 狀態從 Idle 到 Get_XRT_idx_from_CSCB(如圖 13)， 同時將 operand bytes 及 control flags 從 Decode stage 傳給 DSRU，DSRU 之後根據 decode stage 給的 control flags 來決定工作內容，如果發現是要呼叫 method 的動作，則 DSRU

Adjusting return stack Idle Get XRT idx from CSCB Check FLD or MT info Dynamic Class Loading-Parsing Get obj ClassID MT & IF link list searching 3 cycles Native invoke Invoke SW native code Invoke HW logic Get MT or IF info from link list Copy objref to DRC reg. still reading object cache? Method or Interface invocation XRT: Cross-reference table MT: method IF: interface DRC: Dynamic Res. Ctrlr FLD: field ID matches head of list ID does not match head of list matched still searching? class not loaded Execution of a static/native/clinit method, new object, or field access Wait for RISC

response

Wait for HW response 2 cycles

從 Cross Reference Table 找到對應的 method info list，逐一檢查每個 method info 的 cls_id、mthd_id、native_flag (圖 14)。當 DSRU 搜尋到正確的 class ID 與 method ID 時， 其狀態便進入到 Check_FLD_or_MT_info，檢查目前這個 method 相關資料是否已被載入 到 Method Area Circular Buffer 與 Class Symbol Table Circular Buffer，如果沒有則先進入 DynamicClass_Loading_Parsing 狀態，啟動 Class parser 把 class data 與 method bytecode 分別載入 Class Symbol Table Circular Buffer 與 Method Area Circular Buffer 之後，再檢查 native_flag 的值，決定要下個狀態是 MACB_CSCB_Loading 或是 Native_invoke。如果呼 叫的 method bytecode 已被載入到 Method Area Circular Buffer，則不需啟動 Class Parser， 直接判斷 native_flag 決定下個狀態是 Native_invoke 或是 MACB_CSCB_Loading。由於 在此我們舉例 current thread 呼叫 native method，因此，native_flag=1，DSRU 下個狀態 進入 Native_invoke。

Class Symbol Table Circular Buffer Entry 0 Entry 1 (2) (4) pointer . . . (2) (3) (4) _pointer Entry j Entry j+1 . . . Entry n

Cross Reference Table pointer Class ID Class ID Method ID . . . 0xFFFF Class ID (1) Class ID Method ID . . . pointer Class ID Class ID Method ID . . . (1): native_flag native_hardware_flag sync_flag (2) Reserved bits (3)

#bytes for return (4)

Argument size

圖 14 method info list 訪問過程與 method info 格式

native_hardware_flag(圖 14)被用來判斷此 native method 是由 RISC-core 實作與否。 如果其值為 0，表示這個 method 以 RISC-core 實作 interrupt service routine，此時 mthd_id

表示 interrupt service routine ID 編號，且 DSRU 下個狀態進入 Invoke_SW_native_code； 如果其值為 1，表示這個 method 是由 hardwired 電路或加速器實作，此時把 method info 的 method ID 欄位寫入 native_HW_ID 並且 DSRU 下個狀態進入 Invoke_HW_logic。當 DSRU 狀態為 Invoke_HW_logic 時啟動 Hardware Native Interface，把 native_HW_en、 native_HW_ID 這 2 個 Hardware Native Interface 輸出訊號連接個別加速電路模組內。

以圖 10 為例，當 main thread 呼叫 t1.start()或者 t2.start()時會啟動 DSRU，如上一段 描述當 DSRU 到 Cross Reference Table 讀取 Thread.start()的 method info 時發現 native_flag 與 native_hardware_flag 的值皆為 1，因此 DSRU 下個狀態進入 Invoke_HW_logic。根據 圖 12，Hardware Native Interface 的 native_HW_en、native_HW_ID 兩條訊號連接到 ICCU，當 DSRU 狀態為 Invoke_HW_logic，如果 native_HW_en 等於 1 則透過 Hardware Native Interface 觸發 ICCU 執行產生 new thread 的動作，ICCU (圖 19)詳細步驟即將在 section 3-3 描述。當 ICCU 完成產生 new thread 工作之後，native_HW_cmplt 等於 1 且

native_HW_en 等 於 0 ， 此 時 DSRU 的 狀 態 從 Invoke_HW_logic 轉 到

Adjusting_return_stack，把 2-level Java Runtime Stack 回復到呼叫 method 之前的狀態， 最後完成呼叫 start method 的工作。

3.2. Synchronization Operation

為了在 multithreading 環境下支援同步機制，本章節前面有舉例提到 Java 語言提供 Synchronized 保留字，相關實作方式包含 synchronized statement (圖 9(a))與 synchronized method (圖 9(b))，其中 synchronized method 的細節留給個別 Java 平台實做[6]。圖 9的 class B 用 Java compiler 所產生的 method B2、B3 的 bytecode 會包含 monitorenter 與 monitorexit 指令，因此當 TestTH class (圖 10)產生兩個 threads t1, t2 之後每次執行 method B2 或 B3 時，必然會執行到 monitor 相關指令；然而 Class A 編譯過後所產生的 method A2、A3 的 bytecode 並不包含這兩個指令，因此我們在 JAIP 處理器做少部分的修改以 實現 synchonized method 功能。

Complex_flag Fetch stage J_code address translation controller Jcode_pair Mode Controller Translate Stage Decode Stage monitor_enter_req monitor_exit_req jcode_addr Mode_reg 1 0 Stall_fetch jcode_info_AB invoke_sync_flag DSRU Method Area Controller rtn_sync_flag J-code ROM Addr j_code … ... 15 0x00ED 16 0x3031 … …… 25 0xE6FF … …… 35 0x18FF 36 0xF8FF 37 0x78FF ... ….. 49 0x18FF 50 0xF9FF 51 0x78FF 圖 15 Fetch stage 解析複雜指令示意圖

以下先說明 JAIP 處理器的 Bytecode Execution Engine 如何解析 monitorenter 與 monitorexit 並啟動 ICCU，再說明 synchronized method 電路實作方式。圖 15說明 JAIP 的 Fetch stage 讀取 bytecode 複雜指令時，把原本 bytecode 指令轉換成一系列 j_code 指 令再依序傳到 Decode Stage 解析，某些指令如果無法在 1 clock 內於 Fetch、Decode、 Execute stage 完成工作的都被視為複雜指令。根據 Java instruction set 定義，執行 monitorente 與 monitorexit 這 2 個指令之前 Java Stack 的頂端元素必定存放 lock object 的 參考位置，當 current thread 執行這 2 個指令時，便會觸發 Java VM 內部機制，讀取這個 lock object 且檢查是否已經被其他 thread 占用，再回傳訊息給 current thread 判斷 thread state 是否會改變，最後 Java VM 內部執行 pop 的動作將 lock object 參考位置從 Java stack

頂端移除。而 JAIP 與 Data Coherence Controller 無法在 1 clock 內完成以上動作，因此 monitorenter 與 monitorexit 指令在 JAIP 內部被歸類為複雜指令。

當 monitorenter 與 monitorexit 進入 Translate Stage 時，Two-level Java Stack memory 的頂端元素為 lock object 的參考位置，Translate Stage 的輸出訊號 complex_flag 等於 1， 此時 jcode_info_AB 的內容代表 j_code ROM 的參考位置，指向 monitorenter 與 monitorexit 的 j_code 序列中第一個 j_code 位置。j_code ROM 為一個 on-chip block RAM 用來儲存 每個 bytecode 複雜指令所對應到的 j_code 序列，j_code 指令 0xF8 被用來觸發 Decode Stage 的 monitor_enter_req(圖 3-3)，j_code 指令 0xF9 被用來觸發 Decode Stage 的 monitor_exit_req，而 j_code 指令 0x78 代表從 Two-level Java Stack memory 移除一個頂端 元素。0xF8 與 0x78 這 2 個 j_code 在此被用來實做 monitorenter 複雜指令，0xF9 與 0x78 這 2 個 j_code 在此被用來實做 monitorexit 複雜指令，以圖 15 為例，monitorenter 與 monitorexit 對應的 j_code 序列儲存在 j_code ROM 的起始位置分別為 36 與 50。

JAIP Fetch Stage 處理指令 monitorenter 與 monitorexit 的流程皆類似，在此一併描述 其流程。假設目前 Fetch Stage 正在處理 monitorenter 指令，則 mode_reg 的值變成 1， jcode_info_AB=36 傳入 j_code address translation controller (圖 15)，透過其內部電路決定 把 jcode_info_AB 的值傳給 jcode_addr，同時 mode_reg=1 表示 Fetch Stage 目前執行的 是複雜指令。因此從 j_code ROM 讀取的 j_code 會藉由 multiplexer 傳給 j_code_pair，下 個 clock j_code ROM 的訊號輸出為 0xF8 與 0xFF，當 Decode Stage 解析這組 j_code 時會 拉起 monitor_enter_flag，如 section 3-1 描述也會進一步啟動 ICCU，同時 stall_fetch=1 使 j_code ROM 暫停往下讀取下一個 j_code。等到 ICCU 整個執行完畢後，便會恢復整 個 Bytecode Execution Engine 正常運作，意即 stall_fetch=0。Fetch stage 累加 jcode_addr 其值為 37，並且到 j_code ROM 往下讀取一對 j_code 0x78 與 0xFF，移除 Two-level Java Stack memory 頂端元素。之後 complex_flag 與 mode_reg 等於 0，Fetch Stage 開始處理下 一個 bytecode 指令。

為了實做 synchronized method 電路，我們將在 method info 之中加入 synchronized flag (如圖 14的 sync_flag)，呼叫 method 過程中 DSRU 可以藉由 sync_flag 數值判斷是否為

synchronized method，修改 Fetch Stage 的 j_code address translation controller，使 DSRU 與 Method Area Controller 可以傳送信號控制 jcode_addr，我們在 j_code ROM 之中定義 2 組 j_code 序列並命名為 invoke_sync_mthd 與 rtn_sync_mthd，如圖 15所敘述，這 2 個 j_code 序列的起始位置分別為 35 與 49，結束位置分別為 37 與 51，以此方式重複使用 monitorenter 與 monitoerexit 的 j_code 序列；最後在 return frame 中加入 synchronized flag (圖 17)，當執行 return 相關指令時 Method Area Controller 可判斷 synchronized flag 決定 是否需要執行釋放 lock object。 Idle Get XRT idx from CSCB Check FLD or MT info Dynamic Class Loading-Parsing Get obj ClassID MT & IF link list searching 3 cycles Get MT or IF info from link list Copy objref to DRC reg. still reading object cache? Method or Interface invocation XRT: Cross-reference table MT: method IF: interface DRC: Dynamic Res. Ctrlr FLD: field ID matches head of list ID does not match head of list matched still searching? class not loaded Execution of a static/native/clinit method, new object, or field access Stack Init MACB & CSCB Loading 6 cycles DRAM loading done? Request Lock object Synchronized flag is activated DCCCU gets the task done

圖 16 在 DSRU 中呼叫 synchronized method 的流程

當 Class Parser 解析一個 class 過程中如果遇到 synchonized method，則該 method info 24

的 sync_flag=1，Class parser 最後把所有 method_info 資訊依序寫到 cross reference table。 當 current thread 呼叫 method 時會執行相關複雜指令例如 invokevirtual、invokeinterface、 invokestatic 等，Fetch Stage 的 mode_reg=1，啟動 DSRU，其流程如圖 16所示，此時 DSRU 狀態從 Idle 到 Get_XRT_idx_from_CSCB，此時將 return frame 放到 Two-level Java stack memory 的頂端元素 (TOS_A、TOS_B，圖 19)，同時將 operand bytes 及 control flags 從 Decode stage 傳給 DSRU，DSRU 之後根據 decode stage 給的 control flags 來決定工作內 容，如果發現是要呼叫 method 的動作，並且 DSRU 搜尋到正確的 class ID 與 method ID 時，其狀態進入到 Check_FLD_or_MT_info，檢查目前這個 method 相關資料是否已被載 入到 Method Area Circular Buffer 與 Class Symbol Table Circular Buffer，如果沒有則先進 入 DynamicClass_Loading_Parsing 狀態，啟動 Class parser 把 class data 與 method bytecode 分別載入 JAIP 之後，再進入下個狀態 MACB_CSCB_Loading。如果 method bytecode 已 被載入到 Method Area Circular Buffer，則直接進入 MACB_CSCB_Loading。

Cls_id Lv_cnt (1) (2) vp Mthd_id jpc (1) Reserved bit (2) Synchronized bit 1st_{. Entry} 2nd_{. Entry} 圖 17 return frame 格式

Method Area Controller 把呼叫的 method 完全載入到 Method Area Circular Buffer 之 後，DSRU 狀態進入到 Stack_init，此時 stall_fetch=0，所以 j_code ROM 輸出的 j_code 被傳到 jcode_pair 進入 Decode Stage。調整完 local variable pointer (vp)與 stack pointer (sp) 之後，此時 DSRU 內部 register 保存 method info 的訊息，並且呼叫 method 的工作已完 成，vp 指向 current method 的第 1 個 local variable(object 參考位置)。接著檢查 method info 的 sync_flag 訊號，如果是呼叫 synchronized method 則 sync_flag=1，DSRU 狀態從 Stack_init 轉成 Request_Lock_object。此時 2-level Java stack memory 的頂端元素為 return frame 的第一個 entry (圖 17)，故直接把 stack 頂端元素的 synchronized bit 設成 1，DSRU

的 invoke_sync_flag=1，啟動 fetch stage 的 J_code address translation controller(如圖 15)， 此時 jcode_addr=35 指向 invoke_sync_mthd 的 j_code 序列中第一個位置。並且下個 clock 讀取 j_code 0x18 與 0xFF，j_code 0x18 會把 vp 指向的 stack entry(第一個 local variable， lock object 參考位置)加到 stack 頂端，接著 J_code address translation controller 再累加 jcode_addr 的值為 36 使下一組 j_code 0xF8 與 0xFF 被讀取。後續步驟跟上一段執行 monitorenter 的 j_code 序列流程一樣。等到 monitorenter 的 j_code 序列整個執行完畢後， 不管在 Data Coherence Controller 是否成功取得 lock object 權限，此時 mode_reg=0，DSRU 狀態回到 Idle。

當 current thread 在 synchronized method 底下執行 return 相關指令時，2-level Java Stack memory 的頂端 2 個元素(TOS_A、TOS_B，圖 19)分別存放 synchronized method 的 2 個 return frames(圖 17)，Decode Stage 發送訊號讀取 TOS_A 的 synchronized bit 判斷 是否要執行 monitorexit 指令，結束之後再從 Class Symbol Table Circular Buffer 與 Method Area Circular Buffer 載入前一個 method image 與 symbol information(圖 18)，Class Symbol Table Controller 的執行流程與 Method Area Controller 類似，在此一併說明。當 Method Area Controller 狀態為 Get_Offset，如果 return frames 的 synchronized bit = 1 則下個狀態 為 Release_lock_object；否則下個狀態為 Check_Offset。當 Method Area Controller 狀態 為 Release_lock_object，rtn_sync_flag=1 並且啟動 fetch stage 的 J_code address translation controller，此時 jcode_addr=49 指向 rtn_sync_mthd 的 j_code 序列中第一個位置。並且在 下個 clock 讀取 j_code 0x18 與 0xFF，此時 vp、sp 與 synchronized method 的 local variables 存放的位置未被清除，因此透過 vp 載入第一個 local variable(lock object 參考位置)加到 stack 頂端，接著 J_code address translation controller 再累加 jcode_addr 的值為 50 使下一 組 j_code 0xF9 與 0xFF 被讀取。後續步驟跟上一段執行 monitorexit 的 j_code 序列流程 一樣。等到 monitorexit 的 j_code 序列整個執行完畢後，此時 mode_reg=0，Method Area Controller 狀態進入 Check_Offset，開始載入 parent method 的 bytecode。

Wait enable Get Offset Release lock object Check Offset rtn_sync_flag=1 DCCCU gets the job done

Offset Ready The method byteocdes are cached Mthd Loading The related

constant pool data are not cached

Wait_Ack WR_2_M ACB WAIT MST_RD CMPLT

#bytes needed < #bytes loaded

Command ack from bus

Complete writing data with burst length

Complete signal From bus

圖 18 The state diagram of Method Area Controller

3.3. Inter-Core Communication Unit (ICCU)

圖 19 The block diagram of Inter-Core Communication Unit

每個 JAIP 處理器底下的 Inter-Core Communication Unit (ICCU，圖 19)用來負責與 Data Coherence Controller 以及 JAIP 處理器內各個電路模組的溝通。當 DSRU 或者 Decode Stage 送出 request 時，ICCU 會判斷 request 類型，抓取對應的資訊(例如：new thread 的

class ID、method ID、thread object 參考位置、lock object 參考位置以及 current thread ID)， 再發送 request signal 到 Data Coherence Controller 執行工作；而當 Data Coherence Controller 完成處理器發送的 request signal 後便會發送回應訊號給此處理器的 ICCU， ICCU 收到回應訊號便會開始解析回應內容，拉起對應的訊號觸發 DSRU 或 Thread Manager Unit 內某些元件。

JAIP2DCC_cmd Command Description

00 Default value, nothing happened.

01 Acquiring a lock object for the specific thread 10 Release a lock object for the specific thread 11 Assigning new thread to one processor, which

contains minimum number of threads for all of processors.

表 1 ICCU 支援的 request type

Response Status

Corresponding JAIP2DCC_cmd

Description

010 11 When a processor gets the response, it means current thread of a processor is invoking Thread.start(), this processor contains minimum number of threads for all of processors at that time, note both of them could happen on this processor.

100 01 Current thread succeeds in acquiring the specific lock object and owns it, the thread can execute instructions in critical section.

101 01 Current thread fails to acquire the specific lock object and must wait.

110 10 When a processor gets the response, it means the other thread, which is from other processors and owns the lock right now, released the lock, and a thread of this processor become the next owner 111 10 When a processor get the response, it means no other

threads are waiting for the lock at the time after current thread releases the lock.

表 2 ICCU 支援的 response type 28

表 1 與表 2分別說明目前 ICCU 支援的 request 類型與回應訊息類型，以下說明每 種 request 發送訊息的流程。以圖 10為範例，假設 main thread 呼叫 t2.start()產生 new thread 時，DSRU 會啟動 Hardware Native Interface，把 native_HW_en 設成 1 並且啟動 Hardware Native Interface，把輸出訊號傳到 ICCU 同時記錄 DSRU 的 2 個輸出訊號：TH_objref 與 Cls_id_mthd_id 的值，分別表示 thread object 參考位置與 new thread 起始執行的 class ID 與 method ID，藉由 JAIP2DCC_info 把這些資料傳到 Data Coherence Controller。最後 JAIP2DCC_cmd 的值設定為 11，此時發送 request 至 Data Coherence Controller 的工作已 完成。

以圖 10為範例，假設當 thread t2 呼叫 method B3 進入 synchronized statement 欲取 得/釋放 lock object 時，首先 Bytecode Execution Engine 暫停執行指令，根據之前的 2-level Java stack memory 設計(圖 3)，JAIP stack memory 的頂端元素為 TOS_A，此時儲存 lock object 參 考 位 置 ，同 時 Decode Stage 解 析到對 應的 j_code ： monitor_enter_req 或 monitor_exit_req 值為 1 ， 此 時 ICCU 記 錄 TOS_A 值 與 current thread ID ， 藉 由 JAIP2DCC_info 把這些資料傳到 Data Coherence Controller。最後 JAIP2DCC_cmd 的值為 01 或 10，發送 request 至 Data Coherence Controller 的工作已完成。

Receiver core ID [8 : 6] Sender core ID [5 : 3] Response status[2 : 0]

core ID Description

000 Java Core 0 001 Java Core 1 010 Java Core 2 011 Java Core 3

100 RISC Core (Microblaze) 111 Default value

圖 20 DCC2JAIP_response_msg 的格式

接著說明 ICCU 接收與解析 DCC2JAIP_response_msg 的格式，當 Data Coherence 29

Controller 完成工作時會修改 DCC2JAIP_response_msg 並且根據 Sender core ID 與 Receiver core ID 欄位把訊息傳給對應的 JAIP 處理器 (圖 20)。我們將根據表 2個別舉例 說明：

JAIP A (ID=00)

Data Coherence Controller

JAIP D (ID=11) JAIP C (ID=10) JA IP 2 D CC_ cm d JA IP 2 D CC_ cm d JA IP 2 D CC_ cm d D CC2 JA IP _ in fo D CC2 JA IP _ in fo D CC2 JA IP _ in fo JAIP B (ID=01) Inter-Core Communication Unit

Thread Manager Unit Data Transferring

Controller

Command and Status Adaptor JA IP 2 D CC_ cm d D CC2 JA IP _ in fo DCC2JAIP response_msg ICCU_new_TH DCC2JAIP_info TH_new_thread _cmplt

圖 21 ICCU 將 response status 回傳給處理器之示意圖

如圖 21，假設先前 JAIP A 發送的 request 是產生 new thread (JAIP2DCC_cmd = 11)， 並且依照 Data Coherence Controller 內部機制決定將 new thread 分配到 JAIP B，此時 DCC2JAIP_response_msg 為 001000010，Receiver core ID = 001(JAIP B)，Sender core ID = 000(JAIP A)，Data Coherence Controller 透過 DCC2JAIP_info 把 new thread 的 Thread Object 參 考 位 置 、 class ID 與 method ID 傳 到 JAIP B 。 JAIP B 的 ICCU 分 析 DCC2JAIP_response_msg 得知 new thread 執行資訊將被存放在這個處理器內，於是觸發 Data Transferring Controller，接收 DCC2JAIP_info 的 data，並且把 ICCU_new_TH 設成 1 啟動 Thread Controller，利用 Thread Control Block 儲存 new thread 執行資訊，完成工作 後再發送信號到 ICCU。而 JAIP A 收到 DCC2JAIP_response_msg 的回應訊號之後，會檢

查 Receiver core ID 是否等於 Sender core ID，如果相同則 JAIP A 會啟動 Thread Controller，細節步驟皆與上一段描述的相同；否則 Receiver core ID 不等於 Sender core ID，最後 JAIP A 的 ICCU 觸發 Hardware Native Interface 表示執行完 Thread.start()的工作。

JAIP A (ID=00)

Data Coherence Controller

JAIP D (ID=11) JAIP C (ID=10) JA IP 2 D CC_ cm d JA IP 2 D CC_ cm d JA IP 2 D CC_ cm d D CC2 JA IP _ in fo D CC2 JA IP _ in fo D CC2 JA IP _ in fo JAIP B (ID=01) Inter-Core Communication Unit

Thread Manager Unit Data Transferring

Controller

Command and Status Adaptor JA IP 2 D CC_ cm d D CC2 JA IP _ in fo DCC2JAIP response_msg monExit_ nextowner_TH_ID TH_monitor _cmplt ICCU_monEnter_fail ICCU_monExit _nxtOwner

圖 22.ICCU 將 response status 回傳給處理器之示意圖

假設 JAIP B 的 current thread 要取得 lock object L(JAIP2DCC_cmd = 01)，以圖 22為 例 ， Data Coherence Controller 完 成 工 作 後 將 DCC2JAIP_response_msg 的 值 改 為 001001101，Receiver core ID = Sender core ID=001(JAIP B)，而 Response status 為 100 或 101，取決於目前 Data Coherence Controller 是否已存在 lock object L 的紀錄，表示 lock object L 目前已被其他 thread 取得權限。最後更改 ICCU_monEnter_fail 的值，如果該 thread 未成功取得 lock object L 則 ICCU_monEnter_fail = 1 表示 JAIP B 的 current thread 即將進 入 waiting state，因此當 JAIP B 的 Thread Manager Unit 執行 context switch 之後會修改這 個 thread 儲存在 Thread Control Block 的執行資訊；否則 ICCU_monEnter_fail = 0，JAIP B 的 ICCU 收到這個訊號後 Bytecode Execution Engine 恢復執行指令。

假設 JAIP A 的 current thread 釋放 lock ojbect L(JAIP2DCC_cmd=10)，以圖 22為例， 假設在 Data Coherence Controller 發現存在一個以上 waiting thread (s)正在等待取得 lock object L，則 Data Coherence Controller 會決定接下來哪個 waiting thread 能取得 lock object L，在此假設 Data Coherence Controller 將 lock L 的權限轉移到 JAIP B 的某個 waiting thread，則 Data Coherence Controller 完成工作後把下一個取得 lock object L 的 waiting thread ID 傳至 JAIP B、DCC2JAIP_response_msg 的值改為 001000110，Receiver core ID = 001 ， Sender core ID = 000 ， Response status = 110 ， 此 時 ICCU 收 到 訊 號 會 將 monExit_nxtOwner 設成 1，表示 JAIP B 的某個 waiting thread 為 lock object L 的下一個 擁有者。monExit_nextowner_TH_ID 傳入 Thread Manager Unit 把這個 thread 改成 ready state；最後 JAIP A 的 Bytecode Execution Engine 恢復執行指令；如果 Data Coherence Controller 內部不存在任何正在等待 lock object L 的 waiting threads，則 Response status = 111、monExit_nxtOwner = 0，JAIP A 的 Bytecode Execution Engine 直接恢復執行指令。

3.4. Data Coherence Controller

JAIP A JAIP B JAIP C JAIP D

DCC2JAIP response_msg Data Coherence Controller

Cache Coherence Controller Thread Assignment

Controller Lock Object Accessing Controller

Mutex Controller arbiter_cmd_msg arbiter_info new_TH to_coreID lock_obj _match_f lag nxtLock Owner Info ICCU Heap $ ICCU Heap $ ICCU Heap $ ICCU Heap $

圖 23 The block diagram of Data Coherence Controller Data Coherence Controller (圖 23)可分為以下幾個部分：

 Cache Coherence Controller，Java VM 定義 heap space 存放執行時期 Object 與 Array 相關資料，先前多核心 JAIP 處理器環境下每一個 JAIP 內存放一個 2-way set associative Heap Cache 並且採用 Least Recently Used replacement policy 備份資料到 DDR memory。一旦某個 JAIP 執行 heap 相關操作指令例如 new、newarray、 anewarray、arraylength、getfield、putfield，為了確保其他 JAIP 的 heap cache 內容 一致性，這個 JAIP 處理器將透過 JAIP2DCC_info 與 DCC2JAIP_info 把 heap address 與 data 寫入到其他 JAIP 的 heap cache，本論文中保留其原有機制。

 Mutex Controller，如果 2 個以上 JAIP 同時透過 ICCU 發送 request，Data Coherence Controller 必須決定哪一個 request 訊號優先被處理。

 Thread Assignment Controller，先前 JAIP information table [1]內每一個對應 entry 以 core ID 作為索引值用來判斷個別 JAIP 目前是否已被啟動或者閒置。當某個 JAIP 產生 new thread，Thread Assignment Controller 會查詢 JAIP information table 每一個 entry 決定 new thread 被分配到哪一個 JAIP。我們將延伸其 table 設計並用在我們的 架構內。

 Lock Object Accessing Controller，先前 Multi-core coordinator[1]設計中提出一個 Synchronized Manager 處理 Java 同步機制，圖 24描述 Synchronized Manager 的 state controller，當某個 thread A 要取得 lock object，便將 object 參考位置透過 JAIP 傳到 Synchronized Manager 檢查，此時 state 從 Idle 進入 Analysis，如果其他 thread 已先 取得該 lock object 則 thread A 將暫停執行指令，此時 state 從 Analysis 進入 Update Table 等待，直到其他 thread 釋放該 lock object 給 thread A 之後，此時 state 從 Update Table 進入 Idle，thread A 才能繼續往下執行指令；當 thread A 要釋放 lock object， 此時 state 從 Idle 進入 Free Lock，搜尋是否有其他 waiting thread 等待這個 lock object，若存在此 waiting thread 則將 lock object 權限轉移，此時 state 從 Free Lock、 Update Table 回到 Idle。由於先前的設計並未啟用 temporal multithreading 機制，每 一個 JAIP 只包含一個 ready thread，所以先前的設計僅使用 registers 暫存每一個 thread 欲取得的 lock object 狀態，並未考慮如果多個 threads 先後取得單一 lock object

時該如何記錄，如果每一個 thread 執行過程中會取得/釋放不同的 lock object，這會 增加紀錄這些資訊的複雜度。本論文將提出另一設計可以使資源使用最佳化，並且 同時支援多個 lock objects 與 waiting threads。

Update

Table Analysis Idle

Free Lock

圖 24 The state diagram of Synchronized Manager in [1]

3.4.1. Mutex Controller

Thread Assignment Controller Lock Object Accessing Controller

arbiter_info new_TH_to coreID mo n E n _ ma tc h _ c mp lt nxt L o ckO w ne rI n fo la st N ode _l oc k O bj _f la g mutex_state m u te x _ sta te mutex_state m on E n _f re e_c m pl t m on E x _c m pl t

JAIP A JAIP B JAIP C JAIP D

JAIP2DCC _cmd DCC2JAIP response_msg JAIP2DCC _cmd JAIP2DCC _cmd JAIP2DCC _cmd RISC core PLB Bus

圖 25 The block diagram of Mutex Controller

圖 25與圖 26描述 Mutex Controller 的架構，當 2 個以上 JAIP 處理器同時發送 request 時，Arbiter 目的是優先挑選其中一個 request 使這些不同來源的 request 能循序被其他子 模組處理；arbitor_cmd_msg 為 Arbiter 輸出，格式如下：arbitor_cmd_msg[4:2]為 core ID(如 圖 20)，arbitor_cmd_msg[1:0]為 command ID(如表 1)，其儲存的值表示某個 JAIP 處理 器取得權限並且參考 command ID 欄位與 mutex_state 準備觸發 Thread Assignment Controller 或者 Lock Object Accessing Controller，當沒有任何 JAIP 處理器啟動 Mutex Controller 執行工作時，arbitor_cmd_msg 預設值是 11100 SEND RES_MSG WAIT FOR_RES TASK CMPLT IDLE lock_flag = ‘1’ [annotation 1] [next clock] [next clock] CHK_ TCBLIST_RDY [annotation 2] GEN RES_MSG [next clock]

圖 26 The state diagram of Mutex Controller [annotation 1]

根據圖 25的訊號，當 monEn_match_cmplt 為 true、 monEn_free_cmplt 為 true、monEx_cmplt 為 true、

new_TH_to_coreID 不等於 111 其中一個條件成立時，轉移到 下個狀態

[annotation 2]

判斷 DCC2JAIP_response_msg 的 Receiver core ID，檢查對應 JAIP 的 JAIP2DCC_delay_resMsg 數值

lock_flag 為 Arbiter 輸出訊號，其初始值為 0。Arbitor 會決定要優先處理哪個 request signal、lock_flag 由 0 轉為 1 並且 mutex_state 從 Idle 轉為 WAIT_FOR_RES，當 mutex_state = TASK_CMPLT、 lock_flag 值回到 0 才允許從 JAIP 處理器讀取下一個 request 並且修 改 arbitor_cmd_msg；Arbiter_Info 只有當 arbitor_cmd_msg 不等於 111 時，根據不同 core ID 抓取對應 JAIP 處理器的 JAIP2DCC_info；mutex_state 表示目前 state controller 狀態並 且表示目前 Data Coherence Controller 各模組工作階段；new_TH_to_coreID 為 Thread Assignment Controller 工 作 完 成 後 輸 出 的 信 號 ， 其 數 值 代 表 的 意 義 如 同圖 20

DCC2JAIP_response_msg 的 Receiver core ID；monEn_match_cmplt、monEn_free_cmplt、 monEx_cmplt 為 Lock Object Accessing Controller 工 作 完 成 後 輸 出 的 信 號 ； JAIP2DCC_delay_resMsg (圖 26 的 annotation 2)為每一個 JAIP 的 ICCU 連接到 Mutex Controller 的信號，表示個別 JAIP 底下的 Thread Manager Unit 正在更新的 Thread Control Block (e.g. 增加 new thread 的執行資訊、Thread Controller 備份 previous thread 的執行資 訊)；Response Controller 負責傳送回應訊號 DCC2JAIP_response_msg 到各個 JAIP 處理 器的 ICCU。

以圖 10 為範例，當 thread t1 與 t2 分別透過 JAIP A 與 JAIP B 同時呼叫 synchronized method A2，此時由 ICCU 發送 request signal 到 Data Coherence Controller：此時 JAIP A 與 JAIP B 的 JAIP2DCC_cmd 同時不等於 0，mutex_state = Idle、由 Arbiter 判斷讓哪個 JAIP 的 JAIP2DCC_cmd 與 JAIP2DCC_info (圖 19) 分 別 寫 入 arbitor_cmd_msg 與 Arbiter_Info，同時設定 lock_flag 值為 1。假設 Arbiter 優先選擇 JAIP A 的 request，則其 他 JAIP 處理器的 request 必須等到之後 lock_flag 值為 0 且 mutex_state = Idle 時才有機會 將 request 與 data 寫入 arbitor_cmd_msg 與 Arbiter_Info。當 lock_flag 值為 1，mutex_state 從 Idle 到 WAIT_FOR_RES，在這個範例中 arbitor_cmd_msg 值傳入並且啟動 Lock Object Accessing Controller 執行工作。

而當 Thread Assignment Controller 或者 Lock Object Accessing Controller 工作完成後 各個電路回傳訊號(例如 monEn_match_cmplt、monEn_free_cmplt、new_TH_to_coreID) 到 state controller，mutex_state 值從 WAIT_FOR_RES 到 GEN_RES_MSG。當 mutex_state = GEN_RES_MSG，產生回應訊號並且暫存到 Response Controller 的內部暫存器，其格 式與 DCC2JAIP_response_msg 相同；當 mutex_state 為 CHK_TCBLIST_RDY，此時檢 查 Response Controller 中用來儲存回應訊號的內部暫存器，檢查 Receiver core ID 與對應 JAIP 的 JAIP2DCC_delay_resMsg，如果 JAIP2DCC_delay_resMsg = 0 表示 Receiver core ID 對應的 JAIP 處理器其底下 Thread Controller Block 目前沒有被其他電路存取，則 mutex_state 進入 SEND_RES_MSG；否則 JAIP2DCC_delay_resMsg = 1，此 Thread Controller Block 目前已有其他電路更新其內容，Response Controller 必須延後將回應訊

息送給 DCC2JAIP_response_msg。當 mutex_state = SEND_RES_MSG，Response Controller 將回應訊息送給 DCC2JAIP_response_msg，傳到個別 JAIP 處理器的 ICCU。當 mutex_state = TASK_CMPLT、lock_flag 值回到 0、mutex_state 值從 TASK_CMPLT 回到 Idle，此時 Arbiter 檢 查 其 他 JAIP 處 理 器 的 JAIP2DCC_cmd ， 如 果 其 他 JAIP 處 理 器 的 JAIP2DCC_cmd 不等於 111，則把 JAIP2DCC_cmd 寫入 arbitor_cmd_msg 其餘執行流程 相同，否則 arbitor_cmd_msg 被改為預設值。

3.4.2. Thread Assignment Controller

core ID active_TH_num

000 2

001 2

010 2

011 1

圖 27 JAIP information table

圖 27顯示我們修改的 JAIP information table 欄位格式，active_TH_num 為目前某個 JAIP 處 理 器 下 active threads 數 量 。 當 mutex_state = WAIT_FOR_RES 並 且 arbitor_cmd_msg 的 command ID field 等於 11，此時 Arbiter_Info 訊號值代表的是 thread object 的參考位置、起始 class ID 與 method ID，並且開始搜尋 JAIP information table 找 出目前哪一個 JAIP 處理器包含的 thread 數量最少，以決定 new_TH_to_coreID 的值。之 後參考 new_TH_to_coreID 將 Arbiter_Info 輸出到對應 JAIP 的 DCC2JAIP_info，當 mutex_state = SEND_RES_MSG 將回應訊息透過 DCC2JAIP_response_msg 分別傳給呼叫 原本發送此 request 的 JAIP 處理器以及即將儲存 new thread 執行資訊的 JAIP 處理器。

以圖 28 為例，在這個例子中當系統一開始啟動時，JAIP information table 的所有 entries 被歸零，此時所有 JAIP 處於閒置狀態，RISC-core 初始化且由 Class Parser 載入 以及解析必要 Java class images，完成後 RISC-core 把 main method 的 class ID 與 method ID 透過 bus 傳給 Mutex Controller 的 arbiter_info，再依照 arbitor_cmd_msg 格式將二進 位數值 10011 寫入 Mutex Controller 的 arbitor_cmd_msg (圖 28(a)的 step 1)，藉此方式傳