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

1、.：.；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

2、 issues3. Encountered Problems4. 大函式框的處理機制5. 指令摺疊(Paul)前言Java是一個物件導向式的程式語言，具有跨平台及位元碼簡潔的特性。傳統的程式語言，原始碼經由編譯器轉換成某處理器特定的機器碼，該機器碼只能在特定的處理器上執行。假设想在不同的處理器上執行同樣的程式，必須再度运用編譯器將原始碼轉換成另一處理器之機器碼。Java程式語言達成跨平台的方式則是藉由在編譯時將原始碼轉換成位元碼，該位元碼並不是特定處理器之指令，而是虛擬機器之指令。執行Java程式時，可运用位元碼直譯器逐一將位元碼轉換為特定處理器之指令。因此Java程式語言編譯為位元碼之後，可

3、以在任何硬體平台及任何作業系統下運行，只需該平台存在一Java虛擬機器。Java程式語言的缺點在於執行速度。傳統程式語言編譯好的機器碼可以直接在處理器上執行，但Java程式語言編譯出來的位元碼必須經過Java虛擬機器先翻譯成機器碼，然後才干在處理器上運作，多了一道手續。一種解決方式是採用Java處理器。Java處理器可以直接執行位元碼，不需求經過位元碼直譯器的翻譯手續，因此可加速Java程式的運作。Java處理器根本上可分為以下三種型式。第一類是獨立式處理器(stand-alone Java processor)，可獨立運作而不需求搭配另一顆處理器，Sun的picoJava及aJile的aJ-

4、80與aJ-100屬於此類。第二類是協同處理器(Java coprocessor)，需求搭配一顆主處理器來運作，平常運作於主處理器之方式下，需求執行Java程式時，透過協同處理器介面將Java協同處理器喚醒，本身可直接進行Java位元碼的解譯，inSilicon的JVXtreme屬於此類。第三類我們稱為內嵌式轉譯器(embedded Java translator)，內嵌於主處理器之內，在主處理器欲至記憶體存取Java位元碼時，便即時將Java位元碼翻譯為主處理器之機器碼，ARM的Jazelle及Nazomi的JSTAR屬於此類。電通所發表過獨立式Java處理器，這一類處理器的優點是不需求搭配

5、另一顆處理器，本身即可獨立運作，可節省硬體本钱，缺點是需求為處理器開發一系列的發展工具，而且运用者必須花時間學習這一套工具。本論文要介紹的，是電通所對於Java協同處理器的設計。這一類處理器的優點是可运用主處理器上現有之發展工具，运用者不需求學習新的工具。缺點是硬體本钱較高。我們的Java協同處理器所搭配的主處理器是ARM7 TDMI。設計方法2.1 決定援助的位元碼首先我們必須決定Java協同處理器所援助的位元碼集合，援助的位元碼越多，大部份的情況下加速的效果會越好(例外的情況在於對於複雜的指令，有時由主處理器進行處理，比起由Java協同處理器進行處理，反而所需的時間要來得短)，但硬體本钱亦

6、將隨之提高。3.4. 大函式框的處理機制由Java協同處理器對於堆疊快取的設計所致，運行於其上之Java虛擬機器僅能援助函式框大小(該函式之區域變數，框節構及最大堆疊的總合) 在60個項目以下的Java函式。但在Java程式的執行過程中，少數的情況下會遇到函式框大於60的Java函式，因此我們的KVM必須透過軟體的方式來解決這個問題。當函式框大於60，以下稱為大函式框，其他情況則稱為小函式框。我們需求設計及修正的地方包括了：Java協同處理器對於大函式框的處理執行緒的切換與pushFrame，popFrame，throwException相關的部分4.1 Java協同處理器對於大函式框的處理我

7、們為Java協同處理器之狀態暫存器新增一位元，稱為FSO位元(Frame Size Overflow)。當FSO位元被去除時，Java協同處理器遇到可以處理之位元碼，會直接執行，遇到無法處理的位元碼，才交由函式表格內指定之函式進行處理，此時的行為好像本来之Java協同處理器，此方式稱為非FSO方式。而當FSO位元被設定時，Java協同處理器遇到任何位元碼，皆不直接處理，而交由函式表格中專門處理此狀態之函式群負責處理，此方式稱為FSO方式 (此部份之專利正申請中) 。小函式框運行於非FSO方式，而大函式框運行於FSO方式。在KVM中，針對大函式框我們添加了幾個全域變數來儲存大函式框的執行狀態，分

8、別是lp_global，sp_global，fp_global，各代表大函式框執行時的區域變數指標，堆疊頂端指標，目前函式框指標(current frame pointer)。另外亦添加了一FSO變數，其意義等同於Java協同處理器狀態暫存器中之FSO位元，而其存在是為了加速用，可不用每次都得透過Java協同處理器介面來存取FSO狀態，可節省協同處理器介面的額外負擔。當虛擬機器遇到函式呼叫之位元碼時(invokevirtual, invokespecial, invokestatic, invokeinterface)，假设經判斷必須進入大函式框之狀態，便會將Java協同處理器的堆疊快取清空，

9、存入記憶體中，並且抑能堆疊快取，設定Java協同處理器，讓她進入大函式框的執行狀態。此後之堆疊存取便由軟體來負責，執行位元碼的時候還是透過JAExecuteJava，只不過在大函式框的執行方式下，Java協同處理器並不會真的去執行位元碼，只是按照普通小函式框的方式把程式計數器的值作累加，也把該位元碼對應的函式指標傳遞給KVM，讓虛擬機器來執行該位元碼。另外需求修正Java協同處理器的介面函式，本来直接對Java 協同處理器下命令的動作，現在必須判斷是大函式框或是小函式框而採取不同的動作。JAPushStack，JAPopStack，JAWriteStackEntry，JAReadStackEn

10、try必須添加FSO的判斷式來決定要對送出協同處理器指令(mcr/mrc)請Java協同處理器做處理或是直接對記憶體進行操作。除此之外還有JAReadLocalVaribale和JAWriteLocalVaribale，JAReadFrameEntry，JAWriteFrameEntry亦必須参与FSO的判斷式。另外getSP32()，getLP32()，getFP32()這三個函式，當遇到大函式框時，就改成直接傳回sp_global，lp_global，fp_global。透過修正Java協同處理器的介面，好處就是可以讓處理大函式框和小函式框的程式碼幾乎是一樣的，因為判斷的部分在介面的部分處

11、理掉了。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。根據目前的函式是大函式框或小函

12、式框，以及即將執行的函式是大函式框或小函式框，可以分成四種情況。小函式框切換到大函式框小函式框切換到小函式框大函式框切換到大函式框大函式框切換到小函式框當進行函式呼叫的處理時，在pushFrame 函式中必須考慮到這四種情況。當進行函式前往的處理時，在popFrame函式中亦必須考慮到這四種情況。此外，在進行例外處理時，在throwException函式中亦必須考慮到這四種情況。虛擬機器中，popFrame函式的處理方式如下所述：透過FSO的值，我們可以知道目前執行的函式屬於大函式框或是小函式框。由大函式框前往大函式框當目前處於大函式框的狀態，由於Java堆疊都在記憶體中，所以透過fp_glo

13、bal指向框結構中的previousFp，就可以知道之前的函式是大函式框或是小函式框。此時之前的函式亦是大函式框，因此堆疊依然存在記憶體中，我們只需調整sp_global，fp_global，lp_global，設定CP，IP之後便完成popFrame的動作。由大函式框前往小函式框假设之前的函式是小函式框，則我們获得之前的函式的sp,lp,fp之後必須將之轉成7bit的格式放到CurrentThread的JA_CTRL變數，取消FSO 位元，打開SPILL_FILL_BIT，再呼叫loadExecutionEnvironment將這些變數設定到Java協同處理器之中，設定CP，IP便完成了Sm

14、allFrame的設定。由小函式框前往小函式框假设FSO的值為0，我們可得知目前是小函式框，透過硬體获得之前的previousFp可以得知之前的函式是大函式框或是小函式框。假设是小函式框，則按照Java協同處理器的設計，這是預設的情況，透過硬體的指令便可以完成。由小函式框前往大函式框假设之前是大函式框，則需呼叫storeExecutionEnvironment將整個Java 協同處理器包含的堆疊快取清空，存放至記憶體中，設定sp_global，fp_global，lp_global，CP，IP之後便完成pop動作。虛擬機器中，pushFrame的處理情形如下所述：透過FSO的值，可得知目前的函

15、式屬於大框函式或是小框函式。計數下一個函式框的大小(最大堆疊數加上區域變數個數加上框結構之大小)便可得知下一個函式屬於大框函式或是小框函式。由大框函式呼叫大框函式由於堆疊已放於記憶體中，因此設定新的函式框，調整 fp_global，sp_global，lp_global，設定Java協同處理器新的CP，IP，便完成pushFrame的動作。由大框函式呼叫小框函式此時需求進入硬體執行的方式，必須設定CurrentThread的JA_CTRL，將新的sp，lp，fp轉成7 bits設定至Java協同處理器，關掉FSO位元，開啟SPILL_FILL_BIT，將FSO變數設為0，設定新的函式框，設定硬

16、體 CP，IP之後，呼叫loadExecutionEnvironment，讓Java協同處理器重新開始執行。由小框函式呼叫大框函式由於要進入大框函式，因此需呼叫storeExecutionEnvironment將堆疊快取清空，並存放至記憶體中，設定新的函式框，調整lp_global，fp_global，sp_global，開啟FSO位元，關掉SPILL_FILL_BIT，將FSO變數設為1，如此便完成呼叫BigFrame的動作。由小框函式呼叫小框函式這是最單純的情況，設定Java協同處理器的tmpreg0，tmpreg1，tmpreg2後呼叫JAPushFrame便完成。虛擬機器中，throw

17、Exception處理情況如下所述：當Exception發生時，首先呼叫storeExecutionEnvironment將堆疊快取清空，並存放至記憶體中，再由記憶體中的資料來處理。在找尋例外處理函式(exception handler)的過程中，我們能够會不断推出(pop)函式框，由於這時候是在記憶體中處理，所以不論目前處於大框函式或是小框函式，處理方式皆一样。假设找到了例外處理函式，虛擬機器需求執行該函式框之例外處理函式，此時便要重新進行設定，讓Java協同處理器可以執行大框函式及小框函式。之前在不斷推出函式框的過程中，透過函式框中的previousFP，我們可以得知要進入的函式是大框函式或是小框函式，因此當找到例外處理函式時，有兩種能够的狀況需求處理：例外處理函式位於大框函式內由於目前的Java堆疊已經存在於記憶體中，因此僅需求調整sp_gl