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

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

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

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

嵌入式Java虛擬機的設計限制

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

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

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

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

動態(tài)編譯技術

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

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

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

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

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

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

硬件加速

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

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

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

硬件架構擴展和Jazelle DBX技術

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

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

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

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

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

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

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

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

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

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

Jazelle DBX技術的性能

對于一個高度優(yōu)化的商業(yè)Java虛擬機，運行評測程序或復雜的MIDP2.0應用，Jazelle DBX技術通常可帶來約2~4倍的性能提升，而且對實時性不會產生任何影響。

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

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

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

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

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

本文小結

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

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