Java協(xié)同處理器上之虛擬機(jī)器

1、.：.；Java協(xié)同處理器上之虛擬機(jī)器Java Virtual Machine on ARM with CCL Java Coprocessor摘要本篇論文首先描畫從軟體研發(fā)人員的角度, 和CPU團(tuán)隊(duì)共同製定Java協(xié)同處理器時(shí), 所進(jìn)行的研討方法及發(fā)現(xiàn). 本團(tuán)隊(duì)將Java虛擬機(jī)器移植至ARM 7搭配Java協(xié)同處理器之平臺(tái), 並進(jìn)行效能提升, 效果可達(dá)到8倍.關(guān)鍵詞Java Virtual Machine Java虛擬機(jī)器Java Coprocessor Java協(xié)同處理器ARM ARM處理器1. 前言2. Methodology (Steps)2.1 決定援助的位元碼2.2 效能預(yù)估2.3

2、 issues3. Encountered Problems4. 大函式框的處理機(jī)制5. 指令摺疊(Paul)前言Java是一個(gè)物件導(dǎo)向式的程式語(yǔ)言，具有跨平臺(tái)及位元碼簡(jiǎn)潔的特性。傳統(tǒng)的程式語(yǔ)言，原始碼經(jīng)由編譯器轉(zhuǎn)換成某處理器特定的機(jī)器碼，該機(jī)器碼只能在特定的處理器上執(zhí)行。假設(shè)想在不同的處理器上執(zhí)行同樣的程式，必須再度運(yùn)用編譯器將原始碼轉(zhuǎn)換成另一處理器之機(jī)器碼。Java程式語(yǔ)言達(dá)成跨平臺(tái)的方式則是藉由在編譯時(shí)將原始碼轉(zhuǎn)換成位元碼，該位元碼並不是特定處理器之指令，而是虛擬機(jī)器之指令。執(zhí)行Java程式時(shí)，可運(yùn)用位元碼直譯器逐一將位元碼轉(zhuǎn)換為特定處理器之指令。因此Java程式語(yǔ)言編譯為位元碼之後，可

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

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

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

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

7、們?yōu)镴ava協(xié)同處理器之狀態(tài)暫存器新增一位元，稱為FSO位元(Frame Size Overflow)。當(dāng)FSO位元被去除時(shí)，Java協(xié)同處理器遇到可以處理之位元碼，會(huì)直接執(zhí)行，遇到無(wú)法處理的位元碼，才交由函式表格內(nèi)指定之函式進(jìn)行處理，此時(shí)的行為好像本來(lái)之Java協(xié)同處理器，此方式稱為非FSO方式。而當(dāng)FSO位元被設(shè)定時(shí)，Java協(xié)同處理器遇到任何位元碼，皆不直接處理，而交由函式表格中專門處理此狀態(tài)之函式群負(fù)責(zé)處理，此方式稱為FSO方式 (此部份之專利正申請(qǐng)中) 。小函式框運(yùn)行於非FSO方式，而大函式框運(yùn)行於FSO方式。在KVM中，針對(duì)大函式框我們添加了幾個(gè)全域變數(shù)來(lái)儲(chǔ)存大函式框的執(zhí)行狀態(tài)，分

8、別是lp_global，sp_global，fp_global，各代表大函式框執(zhí)行時(shí)的區(qū)域變數(shù)指標(biāo)，堆疊頂端指標(biāo)，目前函式框指標(biāo)(current frame pointer)。另外亦添加了一FSO變數(shù)，其意義等同於Java協(xié)同處理器狀態(tài)暫存器中之FSO位元，而其存在是為了加速用，可不用每次都得透過(guò)Java協(xié)同處理器介面來(lái)存取FSO狀態(tài)，可節(jié)省協(xié)同處理器介面的額外負(fù)擔(dān)。當(dāng)虛擬機(jī)器遇到函式呼叫之位元碼時(shí)(invokevirtual, invokespecial, invokestatic, invokeinterface)，假設(shè)經(jīng)判斷必須進(jìn)入大函式框之狀態(tài)，便會(huì)將Java協(xié)同處理器的堆疊快取清空，

9、存入記憶體中，並且抑能堆疊快取，設(shè)定Java協(xié)同處理器，讓她進(jìn)入大函式框的執(zhí)行狀態(tài)。此後之堆疊存取便由軟體來(lái)負(fù)責(zé)，執(zhí)行位元碼的時(shí)候還是透過(guò)JAExecuteJava，只不過(guò)在大函式框的執(zhí)行方式下，Java協(xié)同處理器並不會(huì)真的去執(zhí)行位元碼，只是按照普通小函式框的方式把程式計(jì)數(shù)器的值作累加，也把該位元碼對(duì)應(yīng)的函式指標(biāo)傳遞給KVM，讓虛擬機(jī)器來(lái)執(zhí)行該位元碼。另外需求修正Java協(xié)同處理器的介面函式，本來(lái)直接對(duì)Java 協(xié)同處理器下命令的動(dòng)作，現(xiàn)在必須判斷是大函式框或是小函式框而採(cǎi)取不同的動(dòng)作。JAPushStack，JAPopStack，JAWriteStackEntry，JAReadStackEn

10、try必須添加FSO的判斷式來(lái)決定要對(duì)送出協(xié)同處理器指令(mcr/mrc)請(qǐng)Java協(xié)同處理器做處理或是直接對(duì)記憶體進(jìn)行操作。除此之外還有JAReadLocalVaribale和JAWriteLocalVaribale，JAReadFrameEntry，JAWriteFrameEntry亦必須參與FSO的判斷式。另外getSP32()，getLP32()，getFP32()這三個(gè)函式，當(dāng)遇到大函式框時(shí)，就改成直接傳回sp_global，lp_global，fp_global。透過(guò)修正Java協(xié)同處理器的介面，好處就是可以讓處理大函式框和小函式框的程式碼幾乎是一樣的，因?yàn)榕袛嗟牟糠衷诮槊娴牟糠痔?/p>

11、理掉了。4.2 執(zhí)行緒的切換主要是修正thread.c中的loadExecutionEnvironment函式，執(zhí)行JALoadThreadContext之後假設(shè)Load進(jìn)來(lái)的執(zhí)行緒是在大函式框中執(zhí)行，那麼必須將sp，fp，lp，設(shè)定給sp_global，fp_global，lp_global，並且將FSO設(shè)為 1。4.3 與pushFrame，popFrame，throwException相關(guān)的部分這部分定義在frame.c裡，除了pushFrame和popFrame這兩個(gè)函式之外還有exception處理的部分，frame.c中的throwException。根據(jù)目前的函式是大函式框或小函

12、式框，以及即將執(zhí)行的函式是大函式框或小函式框，可以分成四種情況。小函式框切換到大函式框小函式框切換到小函式框大函式框切換到大函式框大函式框切換到小函式框當(dāng)進(jìn)行函式呼叫的處理時(shí)，在pushFrame 函式中必須考慮到這四種情況。當(dāng)進(jìn)行函式前往的處理時(shí)，在popFrame函式中亦必須考慮到這四種情況。此外，在進(jìn)行例外處理時(shí)，在throwException函式中亦必須考慮到這四種情況。虛擬機(jī)器中，popFrame函式的處理方式如下所述：透過(guò)FSO的值，我們可以知道目前執(zhí)行的函式屬於大函式框或是小函式框。由大函式框前往大函式框當(dāng)目前處?kù)洞蠛娇虻臓顟B(tài)，由於Java堆疊都在記憶體中，所以透過(guò)fp_glo

13、bal指向框結(jié)構(gòu)中的previousFp，就可以知道之前的函式是大函式框或是小函式框。此時(shí)之前的函式亦是大函式框，因此堆疊依然存在記憶體中，我們只需調(diào)整sp_global，fp_global，lp_global，設(shè)定CP，IP之後便完成popFrame的動(dòng)作。由大函式框前往小函式框假設(shè)之前的函式是小函式框，則我們獲得之前的函式的sp,lp,fp之後必須將之轉(zhuǎn)成7bit的格式放到CurrentThread的JA_CTRL變數(shù)，取消FSO 位元，打開(kāi)SPILL_FILL_BIT，再呼叫l(wèi)oadExecutionEnvironment將這些變數(shù)設(shè)定到Java協(xié)同處理器之中，設(shè)定CP，IP便完成了Sm

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

15、式屬於大框函式或是小框函式。計(jì)數(shù)下一個(gè)函式框的大小(最大堆疊數(shù)加上區(qū)域變數(shù)個(gè)數(shù)加上框結(jié)構(gòu)之大小)便可得知下一個(gè)函式屬於大框函式或是小框函式。由大框函式呼叫大框函式由於堆疊已放於記憶體中，因此設(shè)定新的函式框，調(diào)整 fp_global，sp_global，lp_global，設(shè)定Java協(xié)同處理器新的CP，IP，便完成pushFrame的動(dòng)作。由大框函式呼叫小框函式此時(shí)需求進(jìn)入硬體執(zhí)行的方式，必須設(shè)定CurrentThread的JA_CTRL，將新的sp，lp，fp轉(zhuǎn)成7 bits設(shè)定至Java協(xié)同處理器，關(guān)掉FSO位元，開(kāi)啟SPILL_FILL_BIT，將FSO變數(shù)設(shè)為0，設(shè)定新的函式框，設(shè)定硬

16、體 CP，IP之後，呼叫l(wèi)oadExecutionEnvironment，讓Java協(xié)同處理器重新開(kāi)始執(zhí)行。由小框函式呼叫大框函式由於要進(jìn)入大框函式，因此需呼叫storeExecutionEnvironment將堆疊快取清空，並存放至記憶體中，設(shè)定新的函式框，調(diào)整lp_global，fp_global，sp_global，開(kāi)啟FSO位元，關(guān)掉SPILL_FILL_BIT，將FSO變數(shù)設(shè)為1，如此便完成呼叫BigFrame的動(dòng)作。由小框函式呼叫小框函式這是最單純的情況，設(shè)定Java協(xié)同處理器的tmpreg0，tmpreg1，tmpreg2後呼叫JAPushFrame便完成。虛擬機(jī)器中，throw

17、Exception處理情況如下所述：當(dāng)Exception發(fā)生時(shí)，首先呼叫storeExecutionEnvironment將堆疊快取清空，並存放至記憶體中，再由記憶體中的資料來(lái)處理。在找尋例外處理函式(exception handler)的過(guò)程中，我們能夠會(huì)不斷推出(pop)函式框，由於這時(shí)候是在記憶體中處理，所以不論目前處?kù)洞罂蚝交蚴切】蚝?，處理方式皆一樣。假設(shè)找到了例外處理函式，虛擬機(jī)器需求執(zhí)行該函式框之例外處理函式，此時(shí)便要重新進(jìn)行設(shè)定，讓Java協(xié)同處理器可以執(zhí)行大框函式及小框函式。之前在不斷推出函式框的過(guò)程中，透過(guò)函式框中的previousFP，我們可以得知要進(jìn)入的函式是大框函式或是小框函式，因此當(dāng)找到例外處理函式時(shí)，有兩種能夠的狀況需求處理：例外處理函式位於大框函式內(nèi)由於目前的Java堆疊已經(jīng)存在於記憶體中，因此僅需求調(diào)整sp_gl