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

/Java協同處理器上之虛擬機器JavaVirtualMachineonARMwithCCLJavaCoprocessor摘要本篇論文首先描述從軟體研發人員的角度,和CPU團隊共同製定Java協同處理器時,所進行的研究方法及發現.本團隊將Java虛擬機器移植至ARM7搭配Java協同處理器之平台,並進行效能提升,效果可達到8倍.關鍵詞JavaVirtualMachineJava虛擬機器JavaCoprocessorJava協同處理器ARMARM處理器1.前言2.Methodology(Steps) 2.1決定支援的位元碼2.2效能預估2.3issues3.EncounteredProblems4.大函式框的處理機制5.指令摺疊(Paul)前言傳統的程式語言，原始碼經由編譯器轉換成某處理器特定的機器碼，該機器碼只能在特定的處理器上執行。如果想在不同的處理器上執行同樣的程式，必須再度使用編譯器將原始碼轉換成另一處理器之機器碼。電通所發表過設計方法2.1決定支援的位元碼首先我們必須決定JavaJava3.4.大函式框的處理機制由Java協同處理器對於堆疊快取的設計所致，運行於其上之Java虛擬機器僅能支援函式框大小(該函式之區域變數，框節構及最大堆疊的總合)在60個項目以下的Java函式。但在Java程式的執行過程中，少數的情況下會遇到函式框大於60的Java函式，因此我們的KVM必須透過軟體的方式來解決這個問題。當函式框大於60，以下稱為大函式框，其他情況則稱為小函式框。我們需要設計及修改的地方包括了：Java協同處理器對於大函式框的處理執行緒的切換與pushFrame，popFrame，throwException相關的局部4.1Java協同處理器對於大函式框的處理協同協同協同協同函式框運行於函式框運行於在KVM中針對大函式框我們增加了幾個全域變數來儲存大函式框的執行狀態，分別是lp_global，sp_global，fp_global，各代表大函式框執行時的區域變數指標，堆疊頂端指標，目前函式框指標(currentframepointer)。另外亦增加了一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。根據目前的函式是大函式框或小函式框，以及即將執行的函式是大函式框或小函式框，可以分成四種情況。小函式框切換到大函式框小函式框切換到小函式框大函式框切換到大函式框大函式框切換到小函式框當進行函式呼叫的處理時，在pushFrame函式中必須考慮到這四種情況。當進行函式返回的處理時，在popFrame函式中亦必須考慮到這四種情況。此外，在進行例外處理時，在throwException函式中亦必須考慮到這四種情況。虛擬機器中，popFrame函式的處理方式如下所述：透過FSO的值，我們可以知道目前執行的函式屬於大函式框或是小函式框。由大函式框返回大函式框當目前處於大函式框的狀態，由於Java堆疊都在記憶體中，所以透過fp_global指向框結構中的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便完成了SmallFrame的設定。由小函式框返回小函式框若FSO的值為0，我們可得知目前是小函式框，透過硬體取得之前的previousFp可以得知之前的函式是大函式框或是小函式框。若是小函式框，則按照Java協同處理器的設計，這是預設的情況，透過硬體的指令便可以完成。由小函式框返回大函式框若之前是大函式框，則需呼叫storeExecutionEnvironment將整個Java協同處理器包含的堆疊快取清空，存放至記憶體中，設定sp_global，fp_global，lp_global，CP，IP之後便完成pop動作。虛擬機器中，pushFrame的處理情形如下所述：透過FSO的值，可得知目前的函式屬於大框函式或是小框函式。計數下一個函式框的大小(最大堆疊數加上區域變數個數加上框結構之大小)便可得知下一個函式屬於大框函式或是小框函式。由大框函式呼叫大框函式由於堆疊已放於記憶體中，因此設定新的函式框，調整fp_global，sp_global，lp_global，設定Java協同處理器新的CP，IP，便完成pushFrame的動作。由大框函式呼叫小框函式此時需要進入硬體執行的模式，必須設定CurrentThread的JA_CTRL，將新的sp，lp，fp轉成7bits設定至Java協同處理器，關掉FSO位元，開啟SPILL_FILL_BIT，將FSO變數設為0，設定新的函式框，設定硬體CP，IP之後，呼叫loadExecutionEnvironment，讓Java協同處理器重新開始執行。由小框函式呼叫大框函式由於要進入大框函式，因此需呼叫storeExecutionEnvironment將堆疊快取清空，並存放至記憶體中，設定新的函式框，調整lp_global，fp_global，sp_global，開啟FSO位元，關掉SPILL_FILL_BIT，將FSO變數設為1，如此便完成呼叫BigFrame的動作。由小框函式呼叫小框函式這是最單純的情況，設定Java協同處理器的tmpreg0，tmpreg1，tmpreg2後呼叫JAPushFrame便完成。虛擬機器中，throwException處理情況如下所述：當Exception發生時，首先呼叫storeExecutionEnvironment將堆疊快取清空，並存放至記憶體中，再由記憶體中的資料來處理。在找尋例外處理函式(exceptionhandler)的過程中，我們可能會一直推出(pop)函式框，由於這時候是在記憶體中處理，所以不論目前處於大框函式或是小框函式，處理方式皆相同。如果找到了例外處理函式，虛擬機器需要執行該函式框之例外處理函式，此時便要重新進行設定，讓Java協同處理器可以執行大框函式及小框函式。之前在不斷推出函式框的過程中，透過函式框中的previousFP，我們可以得知要進入的函式是大框函式或是小框函式，因此當找到例外處理函式時，有兩種可能的狀況需要處理：例外處理函式位於大框函式內由於目前的Java堆疊已經存在於記憶體中，因此僅需要調整sp_global，fp_global，lp_global，設定Java協同處理器新的CP，IP，將例外物件(exceptionobject