Java已 經(jīng)在各個(gè)領(lǐng)域得到了廣泛的應(yīng)用，尤其是無(wú)線移動(dòng)領(lǐng)域，全球超過(guò)100個(gè)移動(dòng)運(yùn)營(yíng)商已經(jīng)推出了Java下載服務(wù)。Java也正成為其它嵌入式設(shè)備的支持標(biāo) 準(zhǔn)，如機(jī)頂盒。Java應(yīng)用的快速增長(zhǎng)源于以下幾點(diǎn)：盡管Java的可移植性一直有爭(zhēng)論，但無(wú)庸置疑的是其快速上市的優(yōu)勢(shì)，開(kāi)發(fā)和發(fā)布Java應(yīng)用都很便 捷；Java有著廣泛的支持網(wǎng)絡(luò)，眾多的第三方在開(kāi)發(fā)各色各樣的Java應(yīng)用；Java平臺(tái)固有的安全性適合網(wǎng)絡(luò)下載。

可以說(shuō)，現(xiàn)在Java游戲已經(jīng)發(fā)展成一項(xiàng)產(chǎn)業(yè)，三維圖像、多人連線等更高級(jí)的支持也不鮮見(jiàn)。網(wǎng)絡(luò)運(yùn)營(yíng)商和手機(jī)制造商希望出現(xiàn)更具可玩性的游戲，甚至跳出游戲應(yīng)用發(fā)展諸如商務(wù)、定位、視頻等各種各樣的增值服務(wù)，以帶來(lái)更多的收入。

為支持這些新的服務(wù)，J2ME平臺(tái)必須快速發(fā)展，集成新的API(如移動(dòng)3D)，融入新的特性，比如能夠運(yùn)行多個(gè)MIDlet。移動(dòng)設(shè)備上運(yùn)行Java需要處理好這兩個(gè)問(wèn)題：Java分化和在資源有限的設(shè)備上如何保證Java的性能。

運(yùn)營(yíng)商和手機(jī)制造商為標(biāo)準(zhǔn)Java API加入了許多擴(kuò)展，造成了一定程度上的“Java分化”，影響到了Java的進(jìn)一步應(yīng)用，產(chǎn)業(yè)鏈上各個(gè)環(huán)節(jié)的廠家不得不做額外投入以支持各種擴(kuò)展。于 是Sun公司建立了JCP(Java Community Process)試圖減少這種分化，同時(shí)努力能夠跟上嵌入式設(shè)備上Java應(yīng)用和變化的步伐。現(xiàn)在很多JSR擴(kuò)展規(guī)范都是通過(guò)JCP提出的，證明JCP起 著正面的促進(jìn)作用，能根本上解決分化問(wèn)題。

嵌入式Java虛擬機(jī)的設(shè)計(jì)限制

目前市場(chǎng)上已經(jīng)有大量宣稱支持Java的手機(jī)，從技術(shù)上來(lái)看，許多中低端手機(jī)基本上是在30~50MHz ARM7TDMI處理器上運(yùn)行一個(gè)小型的軟件字節(jié)碼(bytecode)解釋器，相對(duì)較慢。這對(duì)許多的Java小游戲是夠用了，因?yàn)槠湫阅苁怯上到y(tǒng)的圖形 處理能力決定的，對(duì)Java的要求不是特別高。但是市場(chǎng)發(fā)展變化很快，越來(lái)越多的Java應(yīng)用需要更強(qiáng)的圖形處理能力，以及一個(gè)強(qiáng)大的Java虛擬機(jī)。

圖1：指令流水線示意圖。

幾種加快Java執(zhí)行速度的傳統(tǒng)方法包括幾種軟件方案，如字節(jié)碼解釋器優(yōu)化、即時(shí)(JIT, just-in-time)編譯器、預(yù)先(AOT, ahead-of-time)編譯器等；硬件方案有專用Java處理器和Java協(xié)處理器。這些方法在提高性能的同時(shí)，通常也會(huì)增加對(duì)功耗、內(nèi)存的需求， 影響到了系統(tǒng)平臺(tái)的成本，尤其是硬件方案。

JIT或AOT編譯器是把字節(jié)碼動(dòng)態(tài)地編譯成目標(biāo)平臺(tái)的本地碼，然后直接執(zhí)行。顧名思義，AOT編譯方案就是在應(yīng)用下載完后編譯所有代碼，而實(shí)際上 某些代碼很有可能根本就執(zhí)行不到。JIT編譯方案則是運(yùn)行到某段代碼之前，只對(duì)這一段作即時(shí)的編譯。這種即時(shí)處理策略會(huì)讓用戶在選擇啟動(dòng)應(yīng)用程序后，不得 不等待很長(zhǎng)的一段時(shí)間程序才真正運(yùn)行起來(lái)。另外，研究顯示動(dòng)態(tài)編譯會(huì)導(dǎo)致代碼膨脹4~6倍。因此，除了減慢應(yīng)用程序啟動(dòng)速度，無(wú)論JIT還是 AOT方案，都需要很大的額外內(nèi)存來(lái)保存編譯生成的本地碼。

動(dòng)態(tài)編譯技術(shù)

有一種彌補(bǔ)JIT編譯器缺點(diǎn)的方法就是采用通常被稱為動(dòng)態(tài)自適應(yīng)編譯(DAC)的混合軟件方案，它可以看成是JIT編譯器和字節(jié)碼解釋器的組合。在 開(kāi)始階段，程序解釋執(zhí)行，同時(shí)軟件對(duì)代碼作分析并決定哪些關(guān)鍵代碼需要被編譯，這些關(guān)鍵代碼被鑒別出來(lái)后，即被編譯成本地碼運(yùn)行。

采用了DAC方案，JIT編譯的一些負(fù)面影響可能會(huì)減少，但是JIT畢竟無(wú)法提供最好的速度性能，啟動(dòng)時(shí)間和代碼膨脹的問(wèn)題仍會(huì)比較突出。

在完成關(guān)鍵代碼分析前，程序得運(yùn)行于慢速的解釋器模式，然后暫停再進(jìn)行編譯。應(yīng)用程序啟動(dòng)時(shí)，許多函數(shù)方法僅運(yùn)行一次，理想情況下不應(yīng)該編譯這些代碼。從用戶體驗(yàn)角度來(lái)看，影響是很明顯的，尤其是程序啟動(dòng)階段會(huì)感覺(jué)到較長(zhǎng)時(shí)間內(nèi)程序沒(méi)有任何用戶響應(yīng)。

因?yàn)榧冘浖�的解釋器很慢，大多�?shù)DAC方案實(shí)際上很少做代碼分析，而編譯幾乎所有的函數(shù)方法，就像賭博一樣，賭這個(gè)函數(shù)方法接下去會(huì)執(zhí)行很多次。如果賭錯(cuò)，將會(huì)付出更多的代價(jià)—不但花費(fèi)了更多的編譯時(shí)間，而且編譯產(chǎn)生的那些不再運(yùn)行的代碼耗費(fèi)了寶貴的內(nèi)存資源。

編譯的代碼會(huì)占用內(nèi)存資源，DAC必須從內(nèi)存中刪掉以前編譯好的代碼，為新的編譯讓出空間，接下去如果運(yùn)行到剛被刪掉的代碼，又得重新編譯。這樣產(chǎn) 生了性能平滑度問(wèn)題，因?yàn)樵诰幾g新代碼或重編譯過(guò)程中，程序得暫停執(zhí)行。比如在切換游戲場(chǎng)景時(shí)，玩家會(huì)感覺(jué)到難以忍受的等待。

盡管動(dòng)態(tài)編譯存在一些缺點(diǎn)，可現(xiàn)在嵌入式設(shè)備的硬件配置也越來(lái)越高，尤其是RAM或ROM，因此諸如DAC甚至一些AOT方案變得很有吸引力。然 而，我們也看到一個(gè)系統(tǒng)平臺(tái)中許多的組件是用Java開(kāi)發(fā)的，越來(lái)越多的可下載應(yīng)用是用Java寫，多個(gè)Java程序并行執(zhí)行的需求也開(kāi)始產(chǎn)生。這些發(fā)展 趨勢(shì)意味著Java對(duì)內(nèi)存的需求是無(wú)止境的。

硬件加速

硬件Java加速方案通常需要增加額外的芯片以及更多的功耗。專用Java處理器支持直接執(zhí)行Java字節(jié)碼，這雖然看起來(lái)性能不錯(cuò)，但是系統(tǒng)集成和開(kāi)發(fā)的復(fù)雜度卻大幅上升。Java處理器不會(huì)支持已有的很多操作系統(tǒng)和應(yīng)用程序，它需要和其他的嵌入式處理器配合使用。

圖2：采用ARM處理器的Java應(yīng)用嵌入式系統(tǒng)架構(gòu)。

Java協(xié)處理器是把Java字節(jié)碼翻譯成主處理器的指令。這當(dāng)然需要許多軟硬件集成工作，要在操作系統(tǒng)加入對(duì)協(xié)處理器的支持尤其困難。同樣協(xié)處理 器需要額外的板上空間和額外的功耗，而且本身也很貴。另外，協(xié)處理器和主內(nèi)核之間的松耦合連接方式?jīng)Q定了其運(yùn)行速度相對(duì)較慢。

硬件架構(gòu)擴(kuò)展和Jazelle DBX技術(shù)

在已有處理器架構(gòu)上加硬件擴(kuò)展可以同樣支持直接運(yùn)行Java字節(jié)碼，而且保持了操作系統(tǒng)和應(yīng)用程序的兼容性。架構(gòu)擴(kuò)展方案相當(dāng)于為處理器附加了一套 指令集，重用已有的處理器資源不會(huì)增加額外的硬件成本和功耗。帶擴(kuò)展的內(nèi)核能夠同時(shí)執(zhí)行Java字節(jié)碼及本地碼，開(kāi)發(fā)者可以充分利用已有的操作系統(tǒng)、應(yīng)用 程序開(kāi)發(fā)技術(shù)，在Java程序可移植性和性能之間取得很好的平衡。

傳統(tǒng)的ARM處理器都支持兩套指令集：32位ARM指令集和16位Thumb指令集。通常使用Thumb指令集的代碼大小約為ARM代碼的 35~40%，但會(huì)輕微降低程序性能。指令集支持在ARM和Thumb代碼之間互相作函數(shù)調(diào)用，程序員可以在編譯時(shí)分別從性能和代碼密度的角度考慮，以決 定不同部分的代碼編譯成ARM或是Thumb(圖1)。

Jazelle DBX是一種硬件架構(gòu)擴(kuò)展技術(shù)，為ARM處理器引入了第三套指令集—Java字節(jié)碼。新指令集建立了一種新的狀態(tài)，處理器在此狀態(tài)下處理Java字節(jié)碼取指、譯碼和維護(hù)Java操作數(shù)棧。

為了降低芯片尺寸并提高性能，Jazelle DBX沒(méi)有設(shè)計(jì)成傳統(tǒng)形式的微引擎，而是融入流水線中的一個(gè)有限狀態(tài)機(jī)。和協(xié)處理器或?qū)Ｓ锰幚砥髟O(shè)計(jì)不同的是，Jazelle DBX和主處理器共用緩存，這都會(huì)對(duì)功耗和性能帶來(lái)益處。另一個(gè)重要的設(shè)計(jì)考慮是確保Jazelle DBX技術(shù)不會(huì)影響實(shí)時(shí)中斷性能，仍保持與操作系統(tǒng)中已有ARM異常處理代碼的兼容。

Jazelle DBX技術(shù)增加了一條新的“Branch-to-Java”指令來(lái)進(jìn)入Java狀態(tài)。此指令支持條件執(zhí)行，先檢查條件標(biāo)志，如果條件滿足，處理器進(jìn)入Java狀態(tài)，跳轉(zhuǎn)到指定目標(biāo)地址，開(kāi)始執(zhí)行Java字節(jié)碼。

在Java狀態(tài)下，PC寄存器仍是32位尋址Java字節(jié)代碼。字節(jié)碼取指、譯碼分別在兩個(gè)流水級(jí)完成(對(duì)應(yīng)ARM/Thumb狀態(tài)下為一個(gè)譯碼流水級(jí))。32位取指操作一次性可以取4個(gè)Java字節(jié)碼，性能優(yōu)勢(shì)明顯。

當(dāng)前處理器狀態(tài)寄存器(CPSR)新定義了一個(gè)位，用來(lái)記錄處理器的狀態(tài)。這很重要，因?yàn)樵谔幚碇袛嗷蚱渌�異常時(shí)，CPSR會(huì)自動(dòng)保存或恢復(fù)程序運(yùn)行狀態(tài)。

Jazelle DBX技術(shù)允許所有的Java指令是“可重新開(kāi)始”的。這樣在執(zhí)行Java指令過(guò)程中，即刻響應(yīng)中斷，從而減少中斷延遲，確保實(shí)時(shí)性能。

在Java狀態(tài)下，有若干個(gè)ARM寄存器可以功能復(fù)用(包括棧指針、棧頂四項(xiàng)(top4 elements of stack)、局部變量0等)。正是這些硬件復(fù)用設(shè)計(jì)，才使得只用了很少的額外邏輯(約一萬(wàn)兩千門)就實(shí)現(xiàn)了一個(gè)Java機(jī)。把所有Jazelle DBX擴(kuò)展所需的狀態(tài)用ARM寄存器保存，也保證了和現(xiàn)有操作系統(tǒng)、中斷處理程序和異常處理代碼的兼容性。

把棧頂四項(xiàng)保存在ARM寄存器中也能提高Java性能。大量的程序分析顯示，大多數(shù)程序的棧深度是很小的，所以這項(xiàng)策略可以盡量減少內(nèi)存訪問(wèn)，硬件也可自動(dòng)處理?xiàng)Ｒ绯龌蛳乱纭?/p>

Jazelle DBX技術(shù)的性能

對(duì)于一個(gè)高度優(yōu)化的商業(yè)Java虛擬機(jī)，運(yùn)行評(píng)測(cè)程序或復(fù)雜的MIDP2.0應(yīng)用，Jazelle DBX技術(shù)通常可帶來(lái)約2~4倍的性能提升，而且對(duì)實(shí)時(shí)性不會(huì)產(chǎn)生任何影響。

對(duì)于嵌入式設(shè)備來(lái)說(shuō)，運(yùn)行速度還不是唯一的考慮因素，功耗、存儲(chǔ)器占用、集成的難度、系統(tǒng)成本和用戶體驗(yàn)等都很重要，需要很好的平衡。

Jazelle DBX技術(shù)把Java字節(jié)碼分為3類：直接執(zhí)行、模擬執(zhí)行(emulated)和未定義。大多數(shù)Java字節(jié)碼(ARM926EJ-S支持134個(gè))可由 硬件直接執(zhí)行，余下的由一些簡(jiǎn)短的高度優(yōu)化的ARM指令序列模擬執(zhí)行。把原先虛擬機(jī)中的解釋器去掉，替換以ARM專有的代碼(稱為VMZ，這些代碼甚至比 替掉的代碼更小)。

統(tǒng)計(jì)分析表明，在一段典型的程序代碼中，需要模擬執(zhí)行的字節(jié)碼不會(huì)超過(guò)5%。這就是為什么ARM決定Jazelle DBX硬件擴(kuò)展只支持直接執(zhí)行部分的字節(jié)碼，而非全部。Jazelle DBX硬件擴(kuò)展的實(shí)現(xiàn)約為一萬(wàn)兩千門的規(guī)模，而大多數(shù)的專用Java處理器或協(xié)處理器通常有6萬(wàn)到10萬(wàn)門的規(guī)模。這樣的設(shè)計(jì)策略把硬件邏輯的復(fù)雜度減到 最小、功耗低、系統(tǒng)集成難度低，卻仍能表現(xiàn)出很高的整體Java性能。

未定義的字節(jié)碼與模擬執(zhí)行的字節(jié)碼截然不同。一旦執(zhí)行到未定義的字節(jié)碼，處理器退出Java狀態(tài)，進(jìn)入ARM狀態(tài)執(zhí)行異常處理。有了這樣的機(jī)制，就可以以軟件補(bǔ)丁的方式實(shí)現(xiàn)對(duì)未來(lái)可能會(huì)擴(kuò)展的Java字節(jié)碼支持。

為幫助用戶使用Jazelle DBX，ARM公司提供了JTEK件包，其中包含了VMZ源代碼，為一個(gè)現(xiàn)有的Java虛擬機(jī)和操作系統(tǒng)集成JTEK通常只需幾天時(shí)間。ARM也和主流的 Java平臺(tái)供應(yīng)商合作，如Aplix/iasolution和Sun等，在他們的軟件產(chǎn)品中加入了Jazelle DBX支持。另外，ARM和眾多操作系統(tǒng)廠商合作，主流的如WindowsCE、SymbianOS、PalmOS、Linux，以及許多實(shí)時(shí)專有的操作 系統(tǒng)都支持Jazelle DBX。

本文小結(jié)

移動(dòng)Java游戲促進(jìn)了Java在無(wú)線設(shè)備上的應(yīng)用，Java固有的端對(duì)端的安全性和Java應(yīng)用開(kāi)發(fā)的快捷性使Java成為新的收入增長(zhǎng)點(diǎn)。在資 源有限的嵌入式設(shè)備上也需要高性能的Java平臺(tái)，Jazelle DBX這樣的加速技術(shù)正是應(yīng)對(duì)了這樣的需求，其他一些硬件或純軟件加速方案將受益于Jazelle DBX，并避免原有的各種缺點(diǎn)。

通過(guò)融合各種新特性的加入，ARM將在未來(lái)架構(gòu)發(fā)展中繼續(xù)支持Jazelle DBX以及后續(xù)的新技術(shù)。Jazlle技術(shù)和相應(yīng)的JTEK軟件包將更廣泛的促進(jìn)Java在嵌入式設(shè)備上的應(yīng)用，更多更新的移動(dòng)Java應(yīng)用將隨之涌現(xiàn)。