武建平 時(shí) 龍興 凌 明 曹 聞世

(東南大學(xué)國家專用集成電路系統(tǒng)工程技術(shù)研究中心，南京 210096)

Unicore架構(gòu)下的Dalvik虛擬機(jī)優(yōu)化

武建平 時(shí) 龍興 凌 明 曹 聞世

(東南大學(xué)國家專用集成電路系統(tǒng)工程技術(shù)研究中心，南京 210096)

基于Unicore架構(gòu)，對(duì)Dalvik虛擬機(jī)進(jìn)行了移植優(yōu)化.通過分析Unicore架構(gòu)下應(yīng)用程序二進(jìn)制接口與Dalvik虛擬機(jī)的平臺(tái)相關(guān)性，設(shè)計(jì)實(shí)現(xiàn)了jniArgInfo變量字段的布局以及與Dalvik虛擬機(jī)平臺(tái)相關(guān)的本地方法調(diào)用橋.在設(shè)計(jì)完成Unicore架構(gòu)下的快速型解釋器入口函數(shù)、別名寄存器、匯編宏定義以及匯編版本快速型解釋器架構(gòu)等組件的基礎(chǔ)上，結(jié)合虛擬機(jī)快速型解釋器的混合實(shí)現(xiàn)機(jī)制對(duì)Dalvik虛擬機(jī)進(jìn)行了優(yōu)化，并對(duì)優(yōu)化后Dalvik虛擬機(jī)的兼容性、功能、性能進(jìn)行了測試驗(yàn)證.實(shí)驗(yàn)結(jié)果表明，優(yōu)化后的Dalvik虛擬機(jī)符合Android系統(tǒng)規(guī)范，虛擬機(jī)核心部件及Dalvik解釋器性能穩(wěn)定，與優(yōu)化前相比，系統(tǒng)每秒執(zhí)行的字節(jié)碼數(shù)目提升達(dá)147%.與同類平臺(tái)的對(duì)比測試結(jié)果驗(yàn)證了Dalvik虛擬機(jī)性能提升的合理性.

Dalvik虛擬機(jī);Unicore;Android;本地方法調(diào)用橋;解釋器

近年來，隨著以智能手機(jī)［1］為代表的移動(dòng)互聯(lián)終端的飛速發(fā)展，與之配套的智能操作系統(tǒng)(如Windows CE和Windows Mobile系列、蘋果公司的iOS等)開創(chuàng)了移動(dòng)智能終端發(fā)展的新方向.2007年，Google公司正式發(fā)布了第一款 Android系統(tǒng)［2］，它是為移動(dòng)互聯(lián)終端打造的第一個(gè)開放性移動(dòng)軟件平臺(tái).為了創(chuàng)建更加開放的開發(fā)環(huán)境，Google公司組建了開放手機(jī)聯(lián)盟(open handset alliance，OHA)［3］，使得設(shè)備制造商、處理器原廠、第三方應(yīng)用開發(fā)商等業(yè)界產(chǎn)業(yè)鏈圍繞Android系統(tǒng)持續(xù)發(fā)展.從第一款A(yù)ndroid手機(jī)發(fā)布至今不到5年的時(shí)間，Android系統(tǒng)已在移動(dòng)智能終端領(lǐng)域占據(jù)了絕對(duì)領(lǐng)導(dǎo)地位.

當(dāng)前，Android系統(tǒng)絕大部分是基于ARM處理器架構(gòu)的，其主要原因在于:ARM處理器架構(gòu)功耗較低，Android系統(tǒng)可基于ARM處理器架構(gòu)進(jìn)行全面的支持和優(yōu)化.基于國產(chǎn) Unicore架構(gòu)的SoC(system on chip)芯片 SEP6200［4］面向嵌入式移動(dòng)互聯(lián)設(shè)備，以Android系統(tǒng)為基礎(chǔ)軟件平臺(tái).然而，Android系統(tǒng)并未針對(duì)Unicore架構(gòu)進(jìn)行支持和優(yōu)化.

Dalvik虛擬機(jī)是Android系統(tǒng)應(yīng)用程序運(yùn)行的基礎(chǔ)，它通過執(zhí)行特有的字節(jié)碼格式——Dalvik字節(jié)碼來完成對(duì)象生命周期、堆棧、線程、安全異常的管理以及垃圾回收等功能.它依賴于Linux內(nèi)核的部分功能——線程機(jī)制和內(nèi)存管理機(jī)制，能高效使用內(nèi)存，且在CPU低速運(yùn)行時(shí)性能良好.每個(gè)Android應(yīng)用在底層均對(duì)應(yīng)一個(gè)獨(dú)立的Dalvik虛擬機(jī)實(shí)例.虛擬機(jī)的執(zhí)行引擎負(fù)責(zé)Dalvik字節(jié)碼流的解釋執(zhí)行［5］.Dalvik虛擬機(jī)的解釋器提供了多種實(shí)現(xiàn)方式，其中快速型解釋器提供了一種允許混合使用匯編語言和C語言來實(shí)現(xiàn)解釋例程的機(jī)制.與傳統(tǒng)Java虛擬機(jī)相比，Dalvik虛擬機(jī)的最大特點(diǎn)是擁有專用的Dex文件［6］;相對(duì)于Class文件，Dex文件更緊湊，內(nèi)存占用更小，同時(shí)Dalvik字節(jié)碼在執(zhí)行性能上比Class字節(jié)碼更勝一籌.從執(zhí)行流程分析，Dalvik虛擬機(jī)主要由加載器子系統(tǒng)、執(zhí)行引擎和內(nèi)存管理模塊組成.Dalvik虛擬機(jī)的實(shí)現(xiàn)離不開Dx工具、Dalvik字節(jié)碼指令集、運(yùn)行時(shí)常量區(qū)等部分.

本文基于Unicore架構(gòu)進(jìn)行Android系統(tǒng)中核心模塊 Dalvik［7］虛擬機(jī)的移植與優(yōu)化，使得 Android系統(tǒng)能夠流暢運(yùn)行于SEP6200處理器平臺(tái)，主要圍繞Dalvik虛擬機(jī)的實(shí)現(xiàn)與優(yōu)化2個(gè)方面展開.首先，通過分析Unicore架構(gòu)下應(yīng)用程序的二進(jìn)制接口和Dalvik虛擬機(jī)的平臺(tái)相關(guān)性，設(shè)計(jì)了jniArgInfo變量字段的布局.然后，結(jié)合Unicore架構(gòu)的特點(diǎn)，實(shí)現(xiàn)了本地方法調(diào)用橋.設(shè)計(jì)實(shí)現(xiàn)了基于Unicore架構(gòu)的匯編版本快速型解釋器的多個(gè)組件，主要包括快速型解釋器入口函數(shù)、別名寄存器、匯編宏定義以及匯編版本快速型解釋器架構(gòu)，并利用快速型解釋器的混合編程機(jī)制，通過別名寄存器、數(shù)據(jù)布局以及匯編型快速解釋器的構(gòu)建，完成Dalvik虛擬機(jī)的優(yōu)化.

1 Dalvik在Unicore架構(gòu)下的實(shí)現(xiàn)

Java語言本身具備平臺(tái)無關(guān)性，但Dalvik虛擬機(jī)引入的 JNI(Java native interface)機(jī)制［8－9］使得虛擬機(jī)的實(shí)現(xiàn)與平臺(tái)緊密關(guān)聯(lián).Dalvik虛擬機(jī)可屏蔽平臺(tái)間的差異性，故Java語言編寫的Android應(yīng)用程序可以在任何平臺(tái)上運(yùn)行.在Dalvik虛擬機(jī)中，當(dāng)Java方法通過JNI機(jī)制調(diào)用本地方法時(shí)，需要將Java方法中的參數(shù)傳遞給本地方法，而本地方法參數(shù)的傳遞在不同平臺(tái)下存在著各自的約束［10］.為了在不同平臺(tái)上實(shí)現(xiàn)本地方法參數(shù)的傳遞，在JNI架構(gòu)中設(shè)計(jì)了本地方法調(diào)用橋.

Unicore架構(gòu)下，Dalvik虛擬機(jī)的移植實(shí)現(xiàn)關(guān)鍵在于本地方法調(diào)用橋的實(shí)現(xiàn).它隸屬于JNI機(jī)制，與數(shù)據(jù)類型在內(nèi)存中的對(duì)齊要求和函數(shù)調(diào)用規(guī)范相關(guān).本節(jié)主要圍繞本地方法調(diào)用橋的實(shí)現(xiàn)展開，簡單介紹了 JNI機(jī)制及 Unicore架構(gòu)下 ABI(application binary interface)中的數(shù)據(jù)類型布局、寄存器使用和函數(shù)調(diào)用規(guī)范.

1.1 JNI機(jī)制

Android應(yīng)用框架層中的API(application port interface)通過 JNI機(jī)制與系統(tǒng)動(dòng)態(tài)庫或 HAL(hardware abstract level)等本地代碼相關(guān)聯(lián).這些本地方法通過Dalvik虛擬機(jī)中的一個(gè)工具庫nativehelper注冊(cè)到系統(tǒng)，在Java程序中調(diào)用這些本地方法時(shí)用native關(guān)鍵字聲明即可.

JNI機(jī)制的調(diào)用方法包括以下2個(gè)方面:Android系統(tǒng)提供的本地方法和應(yīng)用程序中性能關(guān)鍵部分使用的本地方法.前者以系統(tǒng)動(dòng)態(tài)庫的形式存在，后者以應(yīng)用自帶動(dòng)態(tài)庫的形式存在于 APK(Android package)中.JNI機(jī)制在 Android系統(tǒng)中的調(diào)用方法如圖1所示.

圖1 JNI機(jī)制在Android系統(tǒng)中的調(diào)用流程

JNI機(jī)制實(shí)現(xiàn)的核心數(shù)據(jù)結(jié)構(gòu)是 JNINative-Method.該結(jié)構(gòu)體包含JNI函數(shù)的名稱、參數(shù)和返回值的類型簽名以及JNI函數(shù)對(duì)應(yīng)的本地語言(C/C++)的函數(shù)指針等重要成員.多個(gè)JNINativeMethod結(jié)構(gòu)體變量組成的數(shù)組可以完整地描述一組本地方法，是連接Java方法和本地方法的橋梁.本地方法列表將作為參數(shù)傳遞給registerNativeMethods函數(shù)，該函數(shù)通過調(diào)用JNI機(jī)制提供的jniRegisterNativeMethods函數(shù)對(duì)本地方法進(jìn)行注冊(cè).至此，本地方法已注冊(cè)到系統(tǒng)，可供基于Java語言編寫的上層應(yīng)用程序直接調(diào)用.

1.2 Unicore架構(gòu)下的ABI

通過定制Unicore架構(gòu)下的ABI，使得獨(dú)立編譯、匯編得到的代碼可以被正確地鏈接、執(zhí)行.ABI主要包括存儲(chǔ)布局(數(shù)據(jù)類型布局)、寄存器的使用和函數(shù)調(diào)用規(guī)范3個(gè)方面的內(nèi)容.

1.2.1 數(shù)據(jù)類型布局

Unicore采用小端(小印地安序)存儲(chǔ)，定義8 bit為 byte(字節(jié))、16 bit為 half-word(半字)、32 bit為word(字)，可尋址最小單位為byte.它采用load/store體系結(jié)構(gòu)，對(duì) byte，half-word，word數(shù)據(jù)的讀取和存儲(chǔ)分別由 ldb/std，ldh/sth，dw/stw等指令完成.除基本數(shù)據(jù)類型外，結(jié)構(gòu)體、聯(lián)合、枚舉、數(shù)組等數(shù)據(jù)類型在內(nèi)存中的布局也有各自的要求.對(duì)Unicore架構(gòu)下的基本數(shù)據(jù)類型在內(nèi)存中的對(duì)齊方式進(jìn)行以下說明:所有數(shù)據(jù)類型對(duì)齊方式最大為4 byte對(duì)齊，包括大小為8 byte(64 bit)的 long long和double雙精度類型數(shù)據(jù).與此對(duì)應(yīng)的函數(shù)棧起始地址也是4 byte對(duì)齊.

1.2.2 寄存器的使用

Unicore體系結(jié)構(gòu)提供了46個(gè)通用寄存器、1個(gè)程序計(jì)數(shù)器和6個(gè)狀態(tài)寄存器.與ARM體系結(jié)構(gòu)相同，這些寄存器并非同時(shí)可見，不同操作模式?jīng)Q定著哪些寄存器可見.

同一時(shí)刻一種模式下可見的寄存器包括31個(gè)通用寄存器、1個(gè)程序計(jì)數(shù)器(PC)和1個(gè)或 2個(gè)狀態(tài)寄存器，寬度均為 32 bit.Unicore架構(gòu)下的寄存器比ARM架構(gòu)多一倍，這在 RISC(reduced instruction set computing)體系架構(gòu)中占據(jù)一定的優(yōu)勢(shì).但這種優(yōu)勢(shì)也是相對(duì)的.例如，在15個(gè)寄存器足夠使用的情況下，并不能體現(xiàn)31個(gè)寄存器的優(yōu)勢(shì).特定情況下可利用寄存器數(shù)目多的優(yōu)勢(shì)為Unicore架構(gòu)作進(jìn)一步優(yōu)化.各種模式下寄存器的使用由硬件決定，軟件層同樣存在著寄存器的使用規(guī)則［4］.

1.2.3 函數(shù)調(diào)用規(guī)范

Unicore架構(gòu)中的棧采用滿遞減棧，數(shù)據(jù)的對(duì)齊依賴于其在內(nèi)存中的對(duì)齊方式.保存在棧中的局部變量會(huì)按照對(duì)齊方式對(duì)變量存放的位置進(jìn)行調(diào)整，使其占用的空間最小.最佳方式是將局部變量存放在變量寄存器(R17～R25)中，此時(shí)，保存在寄存器中的變量讀取效率要比存放在棧中的變量高很多.

Unicore架構(gòu)提供了若干指令以支持函數(shù)調(diào)用.最方便的方式是采用BL指令，它會(huì)自動(dòng)將返回地址(當(dāng)前PC地址后的第4個(gè)地址)壓入LR(連接寄存器)中，PC寄存器會(huì)得到即將被調(diào)用的函數(shù)的入口地址.使用BL的結(jié)果是將控制權(quán)轉(zhuǎn)交給被調(diào)用函數(shù)，棧和所有變量寄存器均為被調(diào)用函數(shù)服務(wù).LR作為隱式參數(shù)傳遞給被調(diào)用函數(shù)，以保證函數(shù)的正確返回.

調(diào)用函數(shù)時(shí)應(yīng)遵循相應(yīng)的傳參規(guī)則，類似于ARM架構(gòu)的ATPCS(ARM-thumb procedure call standard).在Unicore架構(gòu)下，總是使用R0～R3傳遞前16 byte數(shù)據(jù)，其他參數(shù)則通過棧進(jìn)行傳遞.傳參類型按以下規(guī)則進(jìn)行:小于4 byte的類型提升為4 byte，保證符號(hào)位不變.將64 bit數(shù)據(jù)作為2個(gè)32 bit數(shù)據(jù)進(jìn)行處理，并將這2個(gè)數(shù)據(jù)存放在連續(xù)的存參空間(依次為 R0，R1，R2，R3和棧)中，高 32 bit數(shù)據(jù)在后，低32 bit數(shù)據(jù)在前.存參空間被視為一段連續(xù)的地址空間，由寄存器和本地棧部分構(gòu)成.將函數(shù)參數(shù)按照上述參數(shù)類型轉(zhuǎn)換規(guī)則轉(zhuǎn)換成以32 bit為單位的參數(shù)數(shù)據(jù)流，按由低到高的順序依次填充即可.

基本類型的最大數(shù)據(jù)寬度為64 bit，將它作為返回值時(shí)最多需要2個(gè)寄存器.在Unicore架構(gòu)下，將標(biāo)量類型作為返回值時(shí)的規(guī)則如下:小于或等于1 word的整形數(shù)據(jù)返回時(shí)，使用R0寄存器;64 bit整形數(shù)使用R0，R1寄存器，其中高32 bit數(shù)據(jù)在R1中;單精度數(shù)據(jù)使用f0返回;雙精度數(shù)據(jù)使用f0，f1返回，高32 bit數(shù)據(jù)在f1中.

1.3 本地方法調(diào)用橋的設(shè)計(jì)與實(shí)現(xiàn)

利用JNI機(jī)制調(diào)用本地方法，實(shí)現(xiàn)參數(shù)傳遞的機(jī)制被稱為本地方法調(diào)用橋.其實(shí)現(xiàn)的關(guān)鍵在于如何填充jniArgInfo變量字段以得到準(zhǔn)確的棧空間大小以及如何將參數(shù)傳遞給本地方法.填充好的jniArgInfo變量將被作為參數(shù)傳遞給dvmPlatformInvoke函數(shù)，該函數(shù)用于處理參數(shù)傳遞并完成本地方法調(diào)用.

jniArgInfo變量攜帶了參數(shù)傳遞時(shí)本地棧需要預(yù)留的空間大小信息，它的設(shè)計(jì)與Unicore架構(gòu)下棧入口地址的對(duì)齊方式以及數(shù)據(jù)在棧中的對(duì)齊方式相關(guān).Unicore架構(gòu)下棧入口地址為4 byte對(duì)齊，jniArgInfo只需要記錄3類信息:參數(shù)個(gè)數(shù)是否合法、返回值類型和參數(shù)個(gè)數(shù).jniArgInfo變量字段的布局如圖2所示.圖中每個(gè)字母代表1 bit，具體定義如下.

S位(bit31):該位為符號(hào)位，用來標(biāo)識(shí)參數(shù)個(gè)數(shù)是否合法.受Dex文件限制，參數(shù)個(gè)數(shù)不能大于0xFFFF.當(dāng)參數(shù)個(gè)數(shù)超過0xFFFF時(shí)，S位會(huì)被寫入“1”而被置位;

R位(bit28～bit30):用來表示本地方法返回類型.

H位(bit0～bit27):用來記錄參數(shù)在存參空間的本地棧部分所占空間大小(以32 bit為單位).由于參數(shù)個(gè)數(shù)最大為0xFFFF，因此需要將H位重新布局.重新布局后的結(jié)果如圖3所示.

圖2 jniArgInfo布局

圖3 H bit布局

圖3中，Z位為預(yù)留位，可以清零;A位記錄了傳遞參數(shù)時(shí)本地棧需要預(yù)留的空間.jniArgInfo變量字段的填充在dvmPlatformInvokeHints函數(shù)中進(jìn)行，實(shí)現(xiàn)的核心是解析signature類型簽名(表示調(diào)用方法的返回值類型、參數(shù)類型等信息)以得到j(luò)niArgInfo變量的S位、R位和A位.當(dāng)參數(shù)個(gè)數(shù)大于0xFFFF時(shí)，則會(huì)調(diào)用dvmAbort異常函數(shù)中止虛擬機(jī)，其原因是當(dāng)一個(gè)本地方法的參數(shù)數(shù)目超過0xFFFF時(shí)，即使符合語法規(guī)則也已經(jīng)不是一個(gè)正常的本地方法.

實(shí)現(xiàn)本地方法調(diào)用橋的關(guān)鍵部分包括參數(shù)傳遞、本地方法調(diào)用及返回，這些功能均由dvmPlatformInvoke函數(shù)實(shí)現(xiàn).實(shí)現(xiàn)流程如圖4所示.

圖4 dvmPlatformInvoke函數(shù)的實(shí)現(xiàn)流程

本地方法調(diào)用橋的核心功能是將解釋器棧中的參數(shù)傳遞給本地方法棧，進(jìn)行本地方法調(diào)用.參數(shù)的傳遞過程如圖5所示.

圖5 本地方法的參數(shù)傳遞示意圖

2 Dalvik虛擬機(jī)的優(yōu)化

Mterp解釋器［11］是Dalvik虛擬機(jī)執(zhí)行引擎的核心.在沒有實(shí)現(xiàn)JIT時(shí)，Mterp解釋器充當(dāng)了執(zhí)行引擎的角色.Dalvik虛擬機(jī)為Mterp解釋器提供了多種實(shí)現(xiàn)方式，包括調(diào)試型、可移植型和快速型解釋器.本文主要通過別名寄存器來存儲(chǔ)關(guān)鍵的變量數(shù)據(jù);構(gòu)建匯編宏定義以表示具有特定意義的常用操作;構(gòu)建匯編版本的解釋例程以實(shí)現(xiàn)匯編版本快速型解釋器，對(duì)Dalvik虛擬機(jī)進(jìn)行優(yōu)化.

2.1 別名寄存器

在Unicore架構(gòu)下，使用匯編實(shí)現(xiàn)快速型解釋器時(shí)，寄存器需要遵守EABI(embedded application binary interface)使用規(guī)則.在Mterp解釋器中，需要經(jīng)常使用幾個(gè)特定的變量或數(shù)據(jù)，可以利用EABI寄存器使用規(guī)則為它們分配空閑、合適的寄存器，最大限度地減少內(nèi)存訪問.這些變量并不在同一函數(shù)內(nèi)，因?yàn)槿绻鼈冊(cè)谕缓瘮?shù)內(nèi)，編譯器即可為它們分配更加合理的寄存器，而無需利用EABI規(guī)則.因此，將與這些變量相關(guān)的函數(shù)采用匯編語言重寫，可以提升解釋執(zhí)行的效率.事實(shí)上，以dvm-MterpStdRun函數(shù)作為入口函數(shù)的Mterp解釋器，采用匯編語言重新編寫，可以最大限度地利用別名寄存器的優(yōu)勢(shì)，將所需要的數(shù)據(jù)直接寫入指定寄存器或從指定寄存器中讀取.此時(shí)，別名寄存器充當(dāng)著全局變量的角色.

2.2 匯編宏定義

匯編版本快速型解釋器構(gòu)建了一系列匯編宏定義，以表示特定的常用操作，這些操作構(gòu)成了解釋例程的基本功能.匯編宏的構(gòu)建為編寫匯編解釋例程帶來了極大便利，使得在實(shí)現(xiàn)解釋例程時(shí)可以更多地關(guān)注解釋例程本身的功能.部分匯編宏的定義見表1.

表1 匯編宏定義表

2.3 匯編版本快速型解釋器的構(gòu)建

匯編版本快速型解釋器的入口函數(shù)與C語言版本的入口函數(shù)保持一致，均為dvmMterpStdRun函數(shù).匯編版本中的入口函數(shù)需要完成以下操作:①本地棧入棧，保存現(xiàn)場;② 將本地棧堆棧指針SP保存到glue結(jié)構(gòu)體中的bailPtr變量中，作為返回地址;③ 初始化rGLUE，rPC，rFP，rIBASE別名寄存器;④ 檢測glue結(jié)構(gòu)體中的entryPoint成員，判斷是否為常規(guī)字節(jié)碼，若不是則進(jìn)行返回、異常等相應(yīng)處理，若是則從rPC指向的字節(jié)碼開始加載、解釋執(zhí)行.對(duì)于入口函數(shù)，匯編版本快速型解釋器必須實(shí)現(xiàn)其出口函數(shù)，當(dāng)執(zhí)行到return等字節(jié)碼時(shí)則會(huì)調(diào)用出口函數(shù)，從而使解釋器退出連續(xù)解釋執(zhí)行的狀態(tài).出口函數(shù)完成如下操作:①恢復(fù)本地棧堆棧指針SP;②將第2個(gè)參數(shù)作為返回值返回;③本地棧出棧，恢復(fù)現(xiàn)場.

在匯編版本快速型解釋器中，為了使字節(jié)碼連續(xù)執(zhí)行，在每個(gè)解釋例程的尾部都會(huì)對(duì)下一條字節(jié)碼進(jìn)行預(yù)取操作，這與其他解釋器的實(shí)現(xiàn)一致.但其他解釋器是通過調(diào)用解釋例程、查表來確定入口地址的，查表意味著內(nèi)存存取操作.在匯編版本快速型解釋器中，則可以通過巧妙的設(shè)計(jì)跳過此操作(見圖6).匯編版本快速型解釋器的解釋例程限制在64 byte空間內(nèi).若64 byte無法完成解釋例程功能，則在dvmAsmSisterStart函數(shù)開始的地方(即附加段)繼續(xù)解釋工作，2段代碼間通過條件或無條件跳轉(zhuǎn)連接.256個(gè)解釋例程按照編碼大小從dvmAsmInstructionStart函數(shù)的地址開始依次排列，其中dvmAsmSisterStart函數(shù)的起始地址為64 byte對(duì)齊，不足64 byte的解釋例程用空指令填充至64 byte.每一個(gè)解釋例程的起始地址均為64 byte對(duì)齊，這種對(duì)齊方式與Cache行大小相匹配，可以加速解釋例程的執(zhí)行.與可移植型解釋器和C語言快速型解釋器相比，匯編版本快速型解釋器具有如下優(yōu)勢(shì):①可利用別名寄存器加速常用變量的存取;②解釋例程描述的功能與匯編語言描述的功能接近，存在大量位段數(shù)據(jù)的存取操作，使得匯編語言的執(zhí)行效率明顯高于高級(jí)語言;③ 通過對(duì)解釋例程巧妙設(shè)計(jì)，避免了確定入口地址時(shí)的查表操作，利用代碼段緩沖行對(duì)齊的特點(diǎn)，最大限度提升了解釋執(zhí)行效率.

圖6 匯編版本快速型解釋器的解釋例程框架

3 實(shí)驗(yàn)與分析

下面從2個(gè)方面對(duì)Unicore架構(gòu)下的Dalvik虛擬機(jī)性能進(jìn)行測試驗(yàn)證.首先，將匯編版本快速型解釋器與C語言版本快速型解釋器、可移植型解釋器的性能進(jìn)行比較，分析性能差異的原因.然后，將SEP6200處理器和S3C6410平臺(tái)［12］下Dalvik虛擬機(jī)優(yōu)化前后的性能進(jìn)行對(duì)比分析.測試硬件平臺(tái)參數(shù)見表2.測試軟件選用專業(yè)虛擬機(jī)性能測試軟件 CaffeineMark［13］.測試項(xiàng)目包括 Sieve，Loop，Logic，String，F(xiàn)loat，Method 和 Overall［14］.測試結(jié)果與CPU主頻相關(guān)，與內(nèi)存大小無關(guān).所有測試結(jié)果均為多次測試結(jié)果的平均值.

表2 對(duì)比測試軟硬件平臺(tái)參數(shù)

3.1 優(yōu)化前后的性能分析

表3列出了可移植型解釋器、C語言版本快速型解釋器和匯編版本快速型解釋器三者的對(duì)比數(shù)據(jù).由表可知，可移植型解釋器與C語言版本快速型解釋器均為thread分發(fā)機(jī)制，兩者均需通過查表確定下一個(gè)解釋例程的入口地址.但前者的每個(gè)解釋例程入口地址為標(biāo)簽，解釋例程之間通過goto語句直接跳轉(zhuǎn)至標(biāo)簽;后者的每個(gè)解釋例程對(duì)應(yīng)一個(gè)函數(shù)，解釋例程之間通過函數(shù)調(diào)用首尾相連.由于函數(shù)調(diào)用比goto語句執(zhí)行耗時(shí)更長，因此，后者的性能略低于前者.從測試結(jié)果來看，前者比后者整體性能提高約6%.

表3 Dalvik虛擬機(jī)解釋器的性能對(duì)比 字節(jié)碼/s

匯編版本快速型解釋器的執(zhí)行速度是C語言版本的2.47倍，其原因在于:① 別名寄存器的使用可以減少對(duì)內(nèi)存的訪問次數(shù)，提升解釋例程的性能.②匯編版本解釋器架構(gòu)下，可以不經(jīng)過查表就能獲取下一個(gè)解釋例程的入口地址;而在C語言版本快速型解釋器中，則需通過查表操作才能確定下一個(gè)解釋例程的入口地址.

3.2 優(yōu)化后的虛擬機(jī)性能

對(duì)比測試平臺(tái)為S3C6410平臺(tái).軟、硬件平臺(tái)參數(shù)信息對(duì)比見表2.

測試數(shù)據(jù)包括C語言版本快速型解釋器和匯編版本快速型解釋器在2個(gè)平臺(tái)下Dalvik虛擬機(jī)的性能數(shù)據(jù)以及優(yōu)化前后性能的對(duì)比數(shù)據(jù).

由表3可知，與C語言版本快速型解釋器相比，Unicore架構(gòu)下的Dalvik虛擬機(jī)采用匯編優(yōu)化后，整體性能提升高達(dá)147%.2款平臺(tái)的對(duì)比實(shí)驗(yàn)結(jié)果顯示:基于S3C6410平臺(tái)，與C語言版本快速型解釋器相比，匯編版本快速型解釋器可實(shí)現(xiàn)2.56倍的性能(即程序執(zhí)行速度)加速比.該結(jié)果比在SEP6200平臺(tái)下采用匯編優(yōu)化后，與C語言版本快速型解釋器相比能達(dá)到的性能加速比(2.47倍)略高.與C語言版本快速型解釋器的性能進(jìn)行對(duì)比是為了具體量化基于SEP6200平臺(tái)優(yōu)化前后Dalvik虛擬機(jī)的性能提升幅度.與S3C6410平臺(tái)下匯編版本快速型解釋器的性能數(shù)據(jù)進(jìn)行對(duì)比，是為了驗(yàn)證SEP6200平臺(tái)下優(yōu)化后的Dalvik虛擬機(jī)的性能提升是否合理.優(yōu)化前SEP6200平臺(tái)下虛擬機(jī)的性能較S3C6410平臺(tái)下虛擬機(jī)的性能略高，尤其是Sieve，F(xiàn)loat子項(xiàng)數(shù)據(jù)更為明顯，說明SEP6200平臺(tái)下虛擬機(jī)的整點(diǎn)、浮點(diǎn)運(yùn)算性能更高.鑒于Unicore匯編指令集的因素，匯編優(yōu)化后并沒有延續(xù)優(yōu)化前的所有優(yōu)勢(shì)，但SEP6200平臺(tái)下虛擬機(jī)的總體性能與S3C6410平臺(tái)下虛擬機(jī)的總體性能相當(dāng)，充分驗(yàn)證了本文針對(duì)Unicore架構(gòu)下Dalvik虛擬機(jī)提出的優(yōu)化方案的有效性.

4 結(jié)語

本文在Unicore架構(gòu)下完成了Dalvik虛擬機(jī)的移植.重點(diǎn)分析了Dalvik虛擬機(jī)與CPU處理器架構(gòu)相關(guān)的部分，包括虛擬機(jī)的 JNI機(jī)制以及Unicore架構(gòu)的ABI.實(shí)現(xiàn)了本地方法調(diào)用橋，構(gòu)建了Unicore架構(gòu)下匯編版本快速型解釋器的各個(gè)組件，并利用快速型解釋器提供的匯編語言和C語言的混合解釋機(jī)制，對(duì)Unicore架構(gòu)下的Dalvik虛擬機(jī)進(jìn)行了性能優(yōu)化.實(shí)驗(yàn)結(jié)果顯示，無論是優(yōu)化前后的縱向?qū)Ρ冗€是與同類平臺(tái)的橫向?qū)Ρ龋疚奶岢龅腄alvik虛擬機(jī)優(yōu)化方案均能明顯提升虛擬機(jī)性能.

［1］Wikipedia.Mobile operating system［EB/OL］.(2011-06-10)［2011-11-15］.http://en.wikipedia.org/wiki/Mobile_operating_system.

［2］Wikipedia.Android(operating system)［EB/OL］.(2011-06-10)［2012-01-13］.http://en.wikipedia.org/wiki/Android_(operating_system).

［3］Open Handset Alliance.Open handset alliance［EB/OL］.(2010-09-20)［2011-12-14］.http://en.wikipedia.org/wiki/Open_Handset_Alliance.

［4］Prochip Corporation.SEP6200 設(shè)計(jì)文檔［EB/OL］.(2010-12-11)［2012-01-14］.http://www.prochip.com.cn/product_show.asp?detailid=27.

［5］Lee Y M，Tak B C，Maeng H S，et.al.Real-time Java virtual machine for information appliances［J］.IEEE Transactions on Consumer Electronics，2000，46(4):949－957.

［6］Google Corporation..dex—Dalvik executable format［EB/OL］. (2011-06-10)［2011-11-25］.http://source.android.com/tech/dalvik/dex-format.html.

［7］Chang C W，Lin C Y，King C T，et al.Implementation of JVM tool interface on Dalvik virtual machine［C］//Proceedings of2010International Symposium on VLSI Design Automation and Test(VLSI-DAT).Hsin Chu，Korea，2010:143－146.

［8］Vladislav Tcheprasov.Template-generated JNI［J］.Journal of C＆C++Users，2004，22(8):38－39.

［9］Bi Lingyan，Wang Weining，Zhong Haobin，et al.Design and application of remote control system using mobile phone with JNI interface［C］//Proceedings of2008International Conference on Embedded Software and Systems Symposia.Beijing，China，2008:416－419.

［10］Qi Minglong，Guo Qingping.Implementing and invoking a remote object calling native methods via RMI-IIOP and JNI［C］//Proceedings of2004International Symposium on Distributed Computing and Applications to Business，Engineering and Science.Wuhan，China，2004:451－456.

［11］Ogata Kazunori，Komatsu Hideaki，Nakatani Toshio.Bytecode fetch optimization for a Java interpreter［C］//Proceedings of the10th International Conference on Architectural Support for Programming Languages and Operating Systems.New York，USA，2002:58－67.

［12］Samsung Corporation.S3C6410 application processor［DB/OL］.(2008-04-01)［2011-12-16］.http://www. samsung. com/global/business/semiconductor/product/application.

［13］Pendragon Software Corporation.CaffeineMark 3.0 information［EB/OL］.(1997)［2011-11-21］.http://www.benchmarkhq.ru/cm30/info.html#Overview.

［14］Google Corporation.Compatibility test suite［EB/OL］.(2011-06-10)［2012-01-11］.http://source.android.com/compatibility/cts-intro.html.

Optimization of Dalvik virtual machine based on Unicore architecture

Wu Jianping Shi Longxing Ling Ming Cao Wenshi
(National ASIC System Engineering Research Center，Southeast University，Nanjing 210096，China)

Based on the Unicore architecture，the Dalvik VM(virtual machine)is transplanted and optimized.First，the relationships between the application binary interfaces of Unicore and Dalvik VM platform are analyzed，and the layout of jniArglnfo's variable field and JNICallbridge(Java native interface Callbridge)which relates with the Dalvik VM are implemented.After several components of the fast interpreter，which includes the entry functions，alias registers，key assembly macro definitions and architecture in assembly version based on Unicore，are implemented，the Dalvik VM is optimized with the mixed mechanism advantage of the fast interpreter.The compatibility，function and performance of the optimized Dalvik VM are tested and verified.The experimental results show that，compared with the system before optimization，the Dalvik VM based on the Unicore architecture fully complies with the Android system.The core partitions and the whole Dalvik interpreter are robust and run steadily.The number of executed bytecode is speedup by 147%per second，and the rationality of the performance gains are verified by comparing with other similar platforms.

Dalvik virtual machine;Unicore;Android;native interface Callbridge;interpreter

TN302

A

1001－0505(2013)01-0017-07

10.3969/j.issn.1001－0505.2013.01.004

2012-05-22.

武建平(1977—)，男，博士生;凌明(聯(lián)系人)，男，博士，副教授，trio@seu.edu.cn.

國家科技重大專項(xiàng)資助項(xiàng)目(2009ZX01031)、江蘇省"青藍(lán)工程"資助項(xiàng)目.

武建平，時(shí)龍興，凌明，等.Unicore架構(gòu)下的Dalvik虛擬機(jī)優(yōu)化［J］.東南大學(xué)學(xué)報(bào):自然科學(xué)版，2013，43(1):17－23.［doi:10.3969/j.issn.1001－0505.2013.01.004］