Java协同处理器上之虚拟机器.doc

Java協同處理器上之虛擬機器Java Virtual Machine on ARM with CCL Java Coprocessor摘要本篇論文首先描述從軟體研發人員的角度, 和CPU團隊共同製定Java協同處理器時, 所進行的研究方法及發現. 本團隊將Java虛擬機器移植至ARM 7搭配Java協同處理器之平台, 並進行效能提升, 效果可達到8倍.關鍵詞Java Virtual Machine Java虛擬機器Java Coprocessor Java協同處理器ARM ARM處理器1. 前言2. Methodology (Steps)2.1 決定支援的位元碼2.2 效能預估2.3 issues3. Encountered Problems4. 大函式框的處理機制5. 指令摺疊(Paul)1. 前言Java是一個物件導向式的程式語言，具有跨平台及位元碼簡潔的特性。傳統的程式語言，原始碼經由編譯器轉換成某處理器特定的機器碼，該機器碼只能在特定的處理器上執行。如果想在不同的處理器上執行同樣的程式，必須再度使用編譯器將原始碼轉換成另一處理器之機器碼。Java程式語言達成跨平台的方式則是藉由在編譯時將原始碼轉換成位元碼，該位元碼並不是特定處理器之指令，而是虛擬機器之指令。執行Java程式時，可使用位元碼直譯器逐一將位元碼轉換為特定處理器之指令。因此Java程式語言編譯為位元碼之後，可以在任何硬體平台及任何作業系統下運行，只要該平台存在一Java虛擬機器。Java程式語言的缺點在於執行速度。傳統程式語言編譯好的機器碼可以直接在處理器上執行，但Java程式語言編譯出來的位元碼必須經過Java虛擬機器先翻譯成機器碼，然後才能在處理器上運作，多了一道手續。一種解決方式是採用Java處理器。Java處理器可以直接執行位元碼，不需要經過位元碼直譯器的翻譯手續，因此可加速Java程式的運作。Java處理器基本上可分為以下三種型式。第一類是獨立式處理器(stand-alone Java processor)，可獨立運作而不需要搭配另一顆處理器，Sun的picoJava及aJile的aJ-80與aJ-100屬於此類。第二類是協同處理器(Java coprocessor)，需要搭配一顆主處理器來運作，平常運作於主處理器之模式下，需要執行Java程式時，透過協同處理器介面將Java協同處理器喚醒，本身可直接進行Java位元碼的解譯，inSilicon的JVXtreme屬於此類。第三類我們稱為內嵌式轉譯器(embedded Java translator)，內嵌於主處理器之內，在主處理器欲至記憶體存取Java位元碼時，便即時將Java位元碼翻譯為主處理器之機器碼，ARM的Jazelle及Nazomi的JSTAR屬於此類。電通所發表過獨立式Java處理器，這一類處理器的優點是不需要搭配另一顆處理器，本身即可獨立運作，可節省硬體成本，缺點是需要為處理器開發一系列的發展工具，而且使用者必須花時間學習這一套工具。本論文要介紹的，是電通所對於Java協同處理器的設計。這一類處理器的優點是可使用主處理器上現有之發展工具，使用者不需要學習新的工具。缺點是硬體成本較高。我們的Java協同處理器所搭配的主處理器是ARM7 TDMI。2. 設計方法2.1 決定支援的位元碼首先我們必須決定Java協同處理器所支援的位元碼集合，支援的位元碼越多，大部份的情況下加速的效果會越好(例外的情況在於對於複雜的指令，有時由主處理器進行處理，比起由Java協同處理器進行處理，反而所需的時間要來得短)，但硬體成本亦將隨之提高。3.4. 大函式框的處理機制由Java協同處理器對於堆疊快取的設計所致，運行於其上之Java虛擬機器僅能支援函式框大小(該函式之區域變數，框節構及最大堆疊的總合) 在60個項目以下的Java函式。但在Java程式的執行過程中，少數的情況下會遇到函式框大於60的Java函式，因此我們的KVM必須透過軟體的方式來解決這個問題。當函式框大於60，以下稱為大函式框，其他情況則稱為小函式框。我們需要設計及修改的地方包括了：1. Java協同處理器對於大函式框的處理2. 執行緒的切換3. 與pushFrame，popFrame，throwException相關的部分4.1 Java協同處理器對於大函式框的處理我們為Java協同處理器之狀態暫存器新增一位元，稱為FSO位元(Frame Size Overflow)。當FSO位元被清除時，Java協同處理器遇到可以處理之位元碼，會直接執行，遇到無法處理的位元碼，才交由函式表格內指定之函式進行處理，此時的行為如同原本之Java協同處理器，此模式稱為非FSO模式。而當FSO位元被設定時，Java協同處理器遇到任何位元碼，皆不直接處理，而交由函式表格中專門處理此狀態之函式群負責處理，此模式稱為FSO模式 (此部份之專利正申請中) 。小函式框運行於非FSO模式，而大函式框運行於FSO模式。在KVM中，針對大函式框我們增加了幾個全域變數來儲存大函式框的執行狀態，分別是lp_global，sp_global，fp_global，各代表大函式框執行時的區域變數指標，堆疊頂端指標，目前函式框指標(current frame pointer)。另外亦增加了一FSO變數，其意義等同於Java協同處理器狀態暫存器中之FSO位元，而其存在是為了加速用，可不必每次都得透過Java協同處理器介面來存取FSO狀態，可節省協同處理器介面的額外負擔。當虛擬機器遇到函式呼叫之位元碼時(invokevirtual, invokespecial, invokestatic, invokeinterface)，若經判斷必須進入大函式框之狀態，便會將Java協同處理器的堆疊快取清空，存入記憶體中，並且抑能堆疊快取，設定Java協同處理器，讓她進入大函式框的執行狀態。此後之堆疊存取便由軟體來負責，執行位元碼的時候還是透過JAExecuteJava，只不過在大函式框的執行模式下，Java協同處理器並不會真的去執行位元碼，只是按照一般小函式框的模式把程式計數器的值作累加，也把該位元碼對應的函式指標傳遞給KVM，讓虛擬機器來執行該位元碼。另外需要修改Java協同處理器的介面函式，原本直接對Java 協同處理器下命令的動作，現在必須判斷是大函式框或是小函式框而採取不同的動作。JAPushStack，JAPopStack，JAWriteStackEntry，JAReadStackEntry必須增加FSO的判斷式來決定要對送出協同處理器指令(mcr/mrc)請Java協同處理器做處理或是直接對記憶體進行操作。除此之外還有JAReadLocalVaribale和JAWriteLocalVaribale，JAReadFrameEntry，JAWriteFrameEntry亦必須加入FSO的判斷式。另外getSP32()，getLP32()，getFP32()這三個函式，當遇到大函式框時，就改成直接傳回sp_global，lp_global，fp_global。透過修改Java協同處理器的介面，好處就是可以讓處理大函式框和小函式框的程式碼幾乎是一樣的，因為判斷的部分在介面的部分處理掉了。4.2 執行緒的切換主要是修改thread.c中的loadExecutionEnvironment函式，執行JALoadThreadContext之後如果Load進來的執行緒是在大函式框中執行，那麼必須將sp，fp，lp，設定給sp_global，fp_global，lp_global，並且將FSO設為 1。4.3 與pushFrame，popFrame，throwException相關的部分這部分定義在frame.c裡，除了pushFrame和popFrame這兩個函式之外還有exception處理的部分，frame.c中的throwException。根據目前的函式是大函式框或小函式框，以及即將執行的函式是大函式框或小函式框，可以分成四種情況。1. 小函式框切換到大函式框2. 小函式框切換到小函式框3. 大函式框切換到大函式框4. 大函式框切換到小函式框當進行函式呼叫的處理時，在pushFrame 函式中必須考慮到這四種情況。當進行函式返回的處理時，在popFrame函式中亦必須考慮到這四種情況。此外，在進行例外處理時，在throwException函式中亦必須考慮到這四種情況。虛擬機器中，popFrame函式的處理方式如下所述：透過FSO的值，我們可以知道目前執行的函式屬於大函式框或是小函式框。1. 由大函式框返回大函式框當目前處於大函式框的狀態，由於Java堆疊都在記憶體中，所以透過fp_global指向框結構中的previousFp，就可以知道之前的函式是大函式框或是小函式框。此時之前的函式亦是大函式框，因此堆疊仍然存在記憶體中，我們只需調整sp_global，fp_global，lp_global，設定CP，IP之後便完成popFrame的動作。2. 由大函式框返回小函式框若之前的函式是小函式框，則我們取得之前的函式的sp,lp,fp之後必須將之轉成7bit的格式放到CurrentThread的JA_CTRL變數，取消FSO 位元，打開SPILL_FILL_BIT，再呼叫loadExecutionEnvironment將這些變數設定到Java協同處理器之中，設定CP，IP便完成了SmallFrame的設定。3. 由小函式框返回小函式框若FSO的值為0，我們可得知目前是小函式框，透過硬體取得之前的previousFp可以得知之前的函式是大函式框或是小函式框。若是小函式框，則按照Java協同處理器的設計，這是預設的情況，透過硬體的指令便可以完成。4. 由小函式框返回大函式框若之前是大函式框，則需呼叫storeExecutionEnvironment將整個Java 協同處理器包含的堆疊快取清空，存放至記憶體中，設定sp_global，fp_global，lp_global，CP，IP之後便完成pop動作。虛擬機器中，pushFrame的處理情形如下所述：透過FSO的值，可得知目前的函式屬於大框函式或是小框函式。計數下一個函式框的大小(最大堆疊數加上區域變數個數加上框結構之大小)便可得知下一個函式屬於大框函式或是小框函式。1. 由大框函式呼叫大框函式由於堆疊已放於記憶體中，因此設定新的函式框，調整 fp_global，sp_global，lp_global，設定Java協同處理器新的CP，IP，便完成pushFrame的動作。2. 由大框函式呼叫小框函式此時需要進入硬體執行的模式，必須設定CurrentThread的JA_CTRL，將新的sp，lp，fp轉成7 bits設定至Java協同處理器，關掉FSO位元，開啟SPILL_FILL_BIT，將FSO變數設為0，設定新的函式框，設定硬體 CP，IP之後，呼叫loadExecutionEnvironment，讓Java協同處理器重新開始執行。3. 由小框函式呼叫大框函式由於要進入大框函式，因此需呼叫storeExecutionEnvironment將堆疊快取清空，並存放至記憶體中，設定新的函式框，調整lp_global，fp_global，sp_global，開啟FSO位元，關掉SPILL_FILL_BIT，將FSO變數設為1，如此便完成呼叫BigFrame的動作。4. 由小框函式呼叫小框函式這是最單純的情況，設定Java協同處理器的tmpreg0，tmpreg1，tmpreg2後呼叫JAPushFrame便完成。虛擬機器中，throwException處理情況如下所述：當Exception發生時，首先呼叫storeExecutionEnvironment將堆疊快取清空，並存放至記憶體中，再由記憶體中的資料來處理。在找尋例外處理函式(exception handler)的過程中，我們可能會一直推出(pop)函式框，由於這時候是在記憶體中處理，所以不論目前處於大框函式或是小框函式，處理方式皆相同。如果找到了例外處理函式，虛擬機器需要執行該函式框之例外處理函式，此時便要重新進行設定，讓Java協同處理器可以執行大框函式及小框函式。之前在不斷推出函式框的過程中，透過函式框中的previousFP，我們可以得知要進入的函式是大框函式或是小框函式，因此當找到例外處理函式時，有兩種可能的狀況需要處理：1. 例外處理函式位於大框函式內由於目前的Java堆疊已經存在於記憶體中，因此僅需要調整sp_glo