ARM硬件支持java技術(shù)Jazelle DBX

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

硬件加速

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

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

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

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

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

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

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

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

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

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

當(dāng)前處理器狀態(tài)寄存器(CPSR)新定義了一個位，用來記錄處理器的狀態(tài)。這很重要，因為在處理中斷或其它異常時，CPSR會自動保存或恢復(fù)程序運行狀態(tài)。

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

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

把棧頂四項保存在ARM寄存器中也能提高Java性能。大量的程序分析顯示，大多數(shù)程序的棧深度是很小的，所以這項策略可以盡量減少內(nèi)存訪問，硬件也可自動處理棧溢出或下溢。

Jazelle DBX技術(shù)的性能

對于一個高度優(yōu)化的商業(yè)Java虛擬機(jī)，運行評測程序或復(fù)雜的MIDP2.0應(yīng)用，Jazelle DBX技術(shù)通?？蓭砑s2~4倍的性能提升，而且對實時性不會產(chǎn)生任何影響。

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

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

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

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

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

本文小結(jié)

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

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