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

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

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

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

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

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

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

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

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

動態編譯技術

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

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

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

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

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

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

硬件加速

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

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

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

硬件架構擴展和Jazelle DBX技術

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

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

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

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

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

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

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

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

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

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

Jazelle DBX技術的性能

對于一個高度優化的商業Java虛擬機，運行評測程序或復雜的MIDP2.0應用，Jazelle DBX技術通�？蓭砑s2~4倍的性能提升，而且對實時性不會產生任何影響。

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

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

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

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

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

本文小結

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

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