易佳望 王斌 肖暉 胡海

摘要： 在移動應(yīng)用開發(fā)中，為了將J2ME技術(shù)應(yīng)用到ARM9嵌入式平臺上，需要事先在該ARM9平臺上成功移植KVM。但是，在將SUN公司的CLDC 1.1參考實現(xiàn)移植到ARM9平臺的過程中，由于編譯工具版本更新導(dǎo)致的編譯工具與參考實現(xiàn)之間的版本不兼容問題，影響了KVM的成功移植。為此，研究了KVM的代碼執(zhí)行機制，并分析了SUN公司的CLDC 1.1參考實現(xiàn)的build過程。在此基礎(chǔ)上，采用目前主流編譯器來移植KVM，對編譯生成KVM各個階段產(chǎn)生的所有錯誤和警告進行了深入分析，并給出了消除那些影響移植結(jié)果的錯誤和警告的適當(dāng)解決方法。所提出的解決方法不僅實現(xiàn)了參考實現(xiàn)源碼的成功編譯，而且提高了移植后KVM程序的健壯性。KVM移植測試的實驗結(jié)果表明，KVM成功地被移植到了ARM9+Embedded Linux平臺上。

關(guān)鍵詞： 移動應(yīng)用開發(fā)； J2ME； CLDC； KVM移植

中圖分類號：TP399文獻(xiàn)標(biāo)志碼：A 文章編號：1006-8228(2012)05-22-04

The research and implementation of KVM porting on ARM9 platforms

Yi Jiawang, Wang Bin, Xiao Hui, Hu Hai

（School of Computer & Communication Engineering, Changsha University of Science & Technology, Changsha, Hunan 410004, China）

Abstract： In mobile application development, we need to successfully port KVM to ARM9 embedded platforms before we use J2ME technology on ARM9 platforms. However, in the process of porting SUN's CLDC 1.1 reference implementation to ARM9 platforms, the version incompatibility problem between compiling tools and the reference implementation, which is brought by version updating of compiling tools, leads to failure in KVM porting. This paper studies the mechanism of executing KVM code, and analyses the building process of SUN's CLDC 1.1 reference implementation. Based on this work, the paper uses currently popular compiling tools to port KVM, analyses in depth all the errors and warnings produced in phases of building KVM, and gives the appropriate solutions to eliminate those errors and warnings which affect the porting result. Solutions proposed in the paper not only achieve the success of compiling reference implementation source code but also improve the robustness of ported KVM programs. The experimental results of KVM porting tests show that KVM is successfully ported to an 'ARM9 + Embedded Linux' platform.

Key words： Mobile application development； J2ME； CLDC； KVM porting

0 引言

目前移動手機上運行的操作系統(tǒng)種類繁多，包括Linux、Windows Mobile、Palm OS、Symbian OS、Google Android等。Java和J2ME技術(shù)克服了手機平臺多樣性造成的應(yīng)用程序移植困難的問題，為移動應(yīng)用程序的跨平臺開發(fā)和運行提供了可能。

J2ME是Sun公司面向具有有限硬件資源的設(shè)備的Java版本，這些資源受限的設(shè)備包括PDA、手機、機頂盒和其它消費電子設(shè)備與嵌入式設(shè)備[1]。CLDC[2]和MIDP[3]已經(jīng)成為用于移動手機應(yīng)用開發(fā)的J2ME標(biāo)準(zhǔn)。

J2ME/CLDC技術(shù)的核心是Sun公司的KVM（Kilobyte Virtual Machine）[4]。KVM最初設(shè)計是用于資源受限的低端移動設(shè)備的JVM（Java virtual machine）。正是JVM的存在才使得Java具有“一次編譯，處處運行”的特征[5,6]，因此，KVM的移植便成為J2ME應(yīng)用于移動開發(fā)的首要前提。

隨著編譯工具的不斷更新，在編譯生成KVM的過程中不可避免地出現(xiàn)了一些影響移植結(jié)果的新問題。對于這些新問題，一部分KVM移植者沿用較低版本的編譯工具以回避版本不兼容問題，而其他移植者雖然處理了新版本編譯器帶來的錯誤但卻忽視了其產(chǎn)生的大多數(shù)警告。這樣做要么使得移植后的KVM與最新編譯的J2ME應(yīng)用仍可能產(chǎn)生版本不兼容問題，要么使得被忽略的那些警告可能導(dǎo)致程序bug從而降低了移植后KVM的程序健壯性或魯棒性。

為了使移植后的KVM能夠穩(wěn)定健壯地運行最新編譯的J2ME應(yīng)用，本文將采用當(dāng)前主流的編譯工具對移植到ARM9平臺上的KVM源碼進行編譯，同時對編譯產(chǎn)生的所有錯誤和警告進行分析和研究，并給出消除這些錯誤和警告的適當(dāng)解決方法。

1 KVM的代碼執(zhí)行機制

為了更好地理解KVM的移植過程，我們需要對KVM的代碼執(zhí)行機制作一些研究。

我們先來看一下JVM的代碼執(zhí)行機制，在此基礎(chǔ)上才能更好地理解KVM的代碼執(zhí)行機制。

[Java源程序

(*.java)][Java字節(jié)碼

(*.class)][Java API類庫

(*.class)][Java虛擬機

(內(nèi)含interpreter)][操作系統(tǒng)及電腦硬件] [Bytecode結(jié)構(gòu)] [編譯] [運行] [翻譯成本地代碼執(zhí)行][加載及校驗][加載及校驗]

圖1JVM的代碼執(zhí)行機制

在圖1中，文本格式的Java源程序（文件后綴名為.java）由Java編譯器編譯為Java字節(jié)碼文件（文件后綴名為.class），且每一個Java類對應(yīng)一個.class文件。

在運行階段，Java虛擬機先裝入或加載指定的“.class”文件，進行必要的校驗，然后找到指定的入口方法（例如main），由interpreter翻譯運行“.class”文件中的字節(jié)碼[7]。虛擬機在執(zhí)行過程中根據(jù)需要（如創(chuàng)建新對象等）動態(tài)加載用戶程序的其他“.class”文件或者系統(tǒng)類庫的“.class”文件并校驗和運行[8]。Java API類庫（一個大型的現(xiàn)成軟件組件（類）集合）是一些為用戶程序運行提供支持或起輔助作用的“.class”格式的標(biāo)準(zhǔn)的Java類，它是Java語言的一個標(biāo)準(zhǔn)組成部分。加載過程通常都是被推遲到必要的時候才進行。

JVM中的interpreter一般采用解釋的方式執(zhí)行字節(jié)碼。它按照程序執(zhí)行的順序逐條取出指令字節(jié)碼，翻譯成一段等效的本地代碼序列來執(zhí)行，這個解釋執(zhí)行過程一直重復(fù)到程序的最后一條指令執(zhí)行完為止[7]。

下面我們再來看一下KVM的代碼執(zhí)行機制（如圖2所示）。

[MyApp.Java][javac] [MyApp.class][preverifier] [預(yù)驗證過的

MyApp.class][verifier] [interpreter][KVM] [下載到目標(biāo)設(shè)備][預(yù)驗證過的

核心API類庫

(*.class)][用JCC處理得到與api類庫對應(yīng)的兩個.c文件][JCC][prelink/prelode][指定CLDC類庫][指定CLDC類庫]

圖2KVM的代碼執(zhí)行機制

我們知道，KVM需要運行在硬件資源受限的嵌入式設(shè)備上，因此有必要對虛擬機的功能進行簡化，提高其運行效率，并減小其體積。為此，將虛擬機原本復(fù)雜而耗資源的大部分校驗工作移出虛擬機，交由PC開發(fā)平臺上一個工具軟件preverify來進行預(yù)驗證或預(yù)校驗，從而減輕移動設(shè)備的負(fù)擔(dān)，而在KVM中只留下一個簡單的輕量級的校驗器[6,9]。

另一方面，由于嵌入式設(shè)備硬件資源的限制和減小體積的需要，CLDC只包括了必要的Java核心類庫。同時，出于安全性考慮，需要將PC開發(fā)平臺上由preverify預(yù)驗證過的CLDC類庫“打包”存放到虛擬機中去。這將由JCC (JavaCodeCompact)工具軟件來負(fù)責(zé)對預(yù)驗證過的CLDC類庫進行處理，并將其預(yù)連接或預(yù)加載（prelink/preload）到KVM中。這樣做也可以避免動態(tài)加載這些類運行時的開銷。

因此，我們在編譯和預(yù)驗證用于KVM的Java代碼時，需要將-classpath選項指定為CLDC類庫的路徑，然后將預(yù)驗證過的class文件下載到目標(biāo)設(shè)備由KVM來執(zhí)行。

2 CLDC參考實現(xiàn)

移植所用的KVM源碼是來自SUN公司的CLDC 1.1參考實現(xiàn)。表1中描述了該CLDC 1.1參考實現(xiàn)源碼包中的目錄結(jié)構(gòu)[4]。

表1CLDC 1.1參考實現(xiàn)的目錄結(jié)構(gòu)

[[子目錄&說明&api&CLDC需要的核心Java類庫源代碼&bin&包含kvm等所有二進制執(zhí)行文件和已編譯好的核心Java類庫的class文件&build&用于編譯生成面向不同操作系統(tǒng)平臺的KVM的makefile&doc&相關(guān)的說明文檔&jam&KVM的可選組件JAM（Java Application Manager）的源碼&kvm&面向不同平臺的KVM的源碼&tools&一些需要用到的工具軟件的源碼，如JavaCodeCompact，preverifier，KDWP Debug Proxy&]]

3 CLDC參考實現(xiàn)的build過程

KVM移植主要是采用合適的編譯工具對CLDC 1.1參考實現(xiàn)中的源碼進行編譯，以生成運行在目標(biāo)平臺上的kvm可執(zhí)行文件。

用于源碼build的Makefile文件根據(jù)源碼目錄的層次結(jié)構(gòu)相應(yīng)地被組織成一個層次結(jié)構(gòu)。主Makefile文件放在build目錄中，由這里跳轉(zhuǎn)去執(zhí)行其它Makefile文件。在build目錄中，根據(jù)目標(biāo)平臺上操作系統(tǒng)的不同類型分別對應(yīng)有不同的主Makefile文件。

在主Makefile文件中可以確定要參與build的代碼段，api部分是必選的，kdp和jcc都是可選的。因為要應(yīng)用于嵌入式系統(tǒng)，故未選擇kdp。對于JAM（Java Application Management），為簡化起見沒有選擇該部分。所有的選擇可以通過修改Makefile文件中的相關(guān)開關(guān)選擇項值進行，也可在命令行中用參數(shù)覆蓋。

以ARM+Linux為目標(biāo)平臺對CLDC參考實現(xiàn)進行build的操作很簡單，只需進入build/linux目錄，通過make命令執(zhí)行那個主Makefile文件，就開始build過程了。下面的圖3描述了其build過程。

[編譯生成preverify工具

(x86平臺可執(zhí)行文件)][編譯和預(yù)驗證api classes，

在壓縮得到class.zip文件

(預(yù)驗證過的api類庫)][編輯生成JCC工具(Java可執(zhí)行程序)，

用JCC處理class.zip得到兩個.c文件，

nativeFunctionTableUnix.c

和ROMjavaUnix.c][將kvm的*.c文件

編譯為*.o目標(biāo)文件][將api類庫對應(yīng)的兩個.c文件

編譯為兩個.o目標(biāo)文件][將kvm的*.o文件和api類庫對應(yīng)的兩個.o文件

連接在一起，生成kvm(ARM平臺可執(zhí)行文件)] [編譯生成kvm，同時將api類庫預(yù)連接到kvm中]

圖3以ARM+Linux為目標(biāo)平臺的build過程

4 CLDC參考實現(xiàn)的源碼編譯

KVM移植所采用的編譯環(huán)境為：Java編譯器Javac 1.6.0_22，（Fedora9自帶）X86平臺Gcc 4.3.0編譯器和交叉編譯器Arm-Linux-Gcc 4.3.2。

首先，KVM的運行平臺是ARM+Linux平臺，所以需要在KVMVmUnixuild目錄中將用于編譯KVM的Makefile文件中的編譯器設(shè)置為交叉編譯器Arm-Linux-Gcc[10]，即：

ifeq($(GCC),true)

CC=arm-linux-gcc

而preverify等工具軟件是運行在X86平臺上的，故無需改變其原采用的編譯器。表2列出了執(zhí)行make命令的過程中各個編譯對象所采用的編譯器。

表2各個編譯對象所采用的編譯器

[[編譯對象&運行平臺&采用編譯器&Preverify Tool&X86&Gcc&Api Classes&NA&Javac&Jcc Tool&X86&Javac&KVM&Arm+Linux&Arm-Linux-Gcc&]]

其次，在最終對KVM源碼進行編譯之前，需要先對所需工具軟件和API類庫進行編譯。因此，CLDC源碼編譯過程包括以下四個階段：編譯生成preverify工具，編譯和預(yù)驗證API類庫，編譯生成JCC工具，編譯和連接生成KVM。

下面我們對CLDC源碼編譯過程中各階段產(chǎn)生的errors和warnings進行分析，并給出適當(dāng)?shù)慕鉀Q方法。

4.1 編譯生成preverify工具

在使用X86 Gcc編譯tools/preverifier目錄下的C源文件時，編譯產(chǎn)生的errors & warnings及其解決方法可以見表3。

表3編譯生成preverify時的錯誤和警告及其解決方法

[[編譯錯誤和警告&解決方法&warning 1：

內(nèi)嵌函數(shù)exit的不兼容隱式聲明&添加語句“#include”&warning 2：

傳遞給iconv函數(shù)的參數(shù)2來自于不兼容指針類型&將第2個參數(shù)from另存為指向非const類型的指針，并改為傳遞該指針&]]

對于表3中給出的解決方法，說明如下。

⑴ warning 1：因為Gcc對函數(shù)exit的隱式聲明和內(nèi)置函數(shù)exit不兼容，所以需要在convert_md.c文件中添加語句“#include ”。

⑵ warning 2：用于字符編碼轉(zhuǎn)換的iconv函數(shù)的聲明為size_t iconv(iconv_t cd, char **inbuf, size_t *inbytesleft, char **outbuf, size_t *outbytesleft);

因為iconv函數(shù)會修改第2個參數(shù)inbuf和第4個參數(shù)outbuf指針?biāo)赶虻牡胤?，而源碼中傳遞給iconv函數(shù)的第2個參數(shù)from是指向const char類型的，其值是不能改變的，所以有警告。

解決方法是將參數(shù)from另存為指向非const類型的指針并改為傳遞該指針，如下所示。

char*from2=(char*)from; //需要進行顯示類型轉(zhuǎn)換

ret=iconv(ic, &from2, &ileft, &to, &oleft);

4.2 編譯和預(yù)驗證api類庫

在使用Javac編譯api目錄下的Java源文件時，編譯產(chǎn)生的errors & warnings及其解決方法可以見表4。

表4編譯api類庫時的錯誤和警告及其解決方法

[[編譯錯誤和警告&解決方法&warning:

不能映射為ASCII編碼的字符&在api/Makefile文件中，對于javac命令添加“-encoding Cp1252”選項&error：

無法訪問java.lang.StringBuilder類文件&在api/Makefile文件中，對于javac命令添加“-source 1.4”選項&]]

對于表4中給出的解決方法，說明如下。

⑴ warning：在將Java源文件編譯為.class文件之前，JDK需要將源程序文本文件從原編碼格式統(tǒng)一轉(zhuǎn)換為Java內(nèi)部默認(rèn)的Unicode格式。

如果不指定Java源文件編碼格式，JDK會以操作系統(tǒng)的默認(rèn)編碼格式作為轉(zhuǎn)換前源文件的編碼格式。這里編譯環(huán)境所用Linux操作系統(tǒng)的默認(rèn)編碼格式是UTF-8（對于英文字母就是ASCII編碼），因此該warning說明轉(zhuǎn)換前源文件編碼格式不是UTF-8。

在vi/vim中可用“:set fileencoding”命令查看源文件字符編碼格式，結(jié)果為fileencoding=latin1，這表示源文件采用的是“Cp1252：Windows Latin-1”編碼。所以，在api目錄下的Makefile文件中，對于javac命令需要使用“-encoding Cp1252”選項指定源文件編碼格式。

⑵ error：java.lang.StringBuilder類是JDK1.5之后出現(xiàn)的[11]。而核心api類庫源文件的版本低于JDK1.6編譯器的版本，所以要在javac命令中使用“-source 1.4”選項指定源碼版本。

4.3 編譯生成jcc工具

在使用javac編譯tools/jcc目錄下的Java源文件時，編譯產(chǎn)生的errors & warnings及其解決方法可以見表5。

對于表5中給出的解決方法，說明如下。

⑴ warning 1：同表4中的warning。

⑵ error：根據(jù)代碼可以判斷這里的enum是用作標(biāo)識符，所以要在javac命令中使用“-source 1.4”選項指定源碼版本（之后enum處會產(chǎn)生false warning）。

⑶ warning 2：可以用Java SE 6 API中的類來替換這兩個Sun專有API類，需要改寫相關(guān)源代碼。為了簡化起見這里暫不處理。

表5編譯生成jcc工具時的錯誤和警告及其解決方法

[[編譯錯誤和警告&解決方法&warning 1：

不能映射為ASCII編碼的字符&在tools/jcc/Makefile文件中，對于javac命令添加“-encoding Cp1252”選項&error：

JDK1.5之后，'enum'是關(guān)鍵詞，不能被用作標(biāo)識符&在tools/jcc /Makefile文件中，對于javac命令添加“-source 1.4”選項&warning 2：

使用了Sun公司專有的API類，即sun.misc.Compare和sun.misc.Sort，未來版本中可能會被移除&目前版本可以支持，暫不處理。&]]

4.4 編譯和連接生成kvm

在使用交叉編譯器Arm-Linux-Gcc編譯KVM目錄下的C源文件時，編譯產(chǎn)生的errors & warnings及其解決方法可以見表6。

表6編譯生成kvm時的錯誤和警告及其解決方法

[[編譯錯誤和警告&解決方法&由兩個靜態(tài)函數(shù)的預(yù)先定義的位置不當(dāng)引起的一系列錯誤和警告&將這兩個靜態(tài)函數(shù)的預(yù)先定義移出所在函數(shù)體，并放在該函數(shù)體前面&warning 1：

整型常數(shù)對于long類型太大&在這些整型常數(shù)或整型常量代表的常數(shù)后面加后綴LL&warning 2：

有三個變量可能會在未初始化賦值的情況下被使用&不作處理，因為程序本身已經(jīng)保證了正確性&warning 3：

定義了但沒有使用的variable和label&不影響程序正確性，可以不處理&error：

_FPU_EXTENDED和

_FPU_DOUBLE沒有被聲明&選擇不編譯相關(guān)的兩個語句，或者將這兩個語句都注釋掉&]]

對于表6中給出的解決方法，說明如下。

⑴ GCC 4.0以上版本不支持將一個靜態(tài)函數(shù)的預(yù)先定義直接放到另一個函數(shù)的函數(shù)體內(nèi)部。因此，需要將兩個靜態(tài)函數(shù)function 'Vfy_verifyMethod'和function 'Vfy_checkNewInstructions'的預(yù)先定義移出到所在函數(shù)體的前面。

⑵ warning 1：因為32位機器的int和long類型都是32位，這些報警的整型常數(shù)已超出32位表示的范圍，所以它們是64位整型常數(shù)，需要在這些整型常數(shù)或整型常量代表的常數(shù)后面加后綴LL（long long類型，交叉編譯器支持該類型）。

⑶ warning 2：報警的原因是，在變量的定義和使用之間存在switch或if-else等多分支語句，而且多分支語句中存在沒有對變量賦值的分支或路徑。這些變量分別是'typeKey'、'targetClassKey'和'thisClass'。經(jīng)檢查，程序中可以保證這些變量在有效使用前都已被初始化賦值過，故無需處理。

⑷ warning 3：略。

⑸ error：在kvm/VmUnix/h目錄下的machine_md.h文件中，將編譯開關(guān)選項PROCESSOR_ARCHITECTURE_X86的定義改為0，選擇不編譯函數(shù)function 'InitializeFloatingPoint'內(nèi)的兩個語句（也可以簡單注釋掉這兩個語句）。因為該函數(shù)只是用來設(shè)置X86 CPU集成的FPU的精度模式，所以不編譯這兩個語句并不影響針對ARM處理器所生成的KVM對浮點的支持。

5 移植結(jié)果測試

移植測試采用的目標(biāo)開發(fā)板平臺為S3C2440+Embedded Linux 2.6.32.2。

按以上方法解決編譯時產(chǎn)生的errors和warnings后，可以得到一個KVM可執(zhí)行文件。在Linux終端中輸入命令：file kvm，將顯示該KVM是一個ARM平臺的可執(zhí)行文件，需要下載到ARM開發(fā)板上運行。

編寫一個“Hello World！”Java源程序，編譯和預(yù)驗證時指定-classpath選項為CLDC類庫。在Linux終端中輸入如下命令：

[root@tom home]# javac -source 1.4 -classpath/home/

j2me_cldc/api/classes -d /home/examples Hello.java

[root@tom home]# preverify -classpath/home/j2me_cldc/api/

classes -d ./home/examples

這里要注意Javac命令要加選項-source 1.4，指定源碼版本。

最后，將預(yù)驗證過的Hello.class下載到開發(fā)板上KVM可執(zhí)行文件所在的目錄中，在開發(fā)板終端中執(zhí)行命令：./kvm Hello，可以看到“Hello World！”的輸出，如圖4所示。這說明KVM移植成功（該KVM支持浮點運算）。

圖4KVM移植結(jié)果測試

6 結(jié)束語

本文采用目前主流版本的編譯器來移植KVM，對KVM源碼編譯各個階段所產(chǎn)生的錯誤和警告進行了深入分析，并給出了消除它們的適當(dāng)解決方法。這些解決方法一方面消除了主要由編譯器版本更新導(dǎo)致的錯誤，實現(xiàn)了KVM的成功編譯；另一方面消除了那些可能會導(dǎo)致KVM程序bug的警告，提高了移植后KVM程序的健壯性或魯棒性。KVM移植結(jié)果的測試實驗表明，按本文所述解決方法消除相關(guān)錯誤和警告后編譯所得的KVM被成功地移植到了ARM9嵌入式平臺上。

本文可以為以后新編譯環(huán)境下成功移植KVM提供有益的參考。為了在ARM9平臺上實現(xiàn)J2ME的應(yīng)用，我們進一步的工作將是在成功移植功能完整的KVM的基礎(chǔ)上移植MIDP 2.0。

參考文獻(xiàn)：

[1] 馮東,羅蕾.MTK系統(tǒng)下的J2ME運行平臺設(shè)計[J].單片機與嵌入式

系統(tǒng)應(yīng)用,2009.4.

[2] Sun Microsystem,Inc.Connected Limited Device Configuration

(CLDC).http://java.sun.com/products/cldc/.

[3] Sun Microsystem, Inc. Mobile Information Device Profile(MIDP).

http://java.sun.com/products/midp/.

[4] Sun Microsystems, Inc. KVM Porting Guide, CLDC 1.1, J2ME,

March 2003.

[5] Sun Microsystems, Inc. The Java Virtual Machine Specification,

Second Edition,1999.

[6] 周顯軍,李眾立,張俊然.基于S3C4510B芯片KVM虛擬機的移植和

測試[J].微計算機信息,2007.23(10-2).

[7] 馬嘉,周明天,陳虹.一種基于ARM7的嵌入式Java虛擬機性能優(yōu)化

技術(shù)研究[J].計算機應(yīng)用研究,2007.24(5).

[8] Bill Venners.曹曉剛,蔣靖譯.深入Java虛擬機[M].機械工業(yè)出版社,

2007.

[9] 葉磊,陳榕,趙岳松.KVM在基于構(gòu)件的嵌入式操作系統(tǒng)上的移植和

研究[J].計算機應(yīng)用研究,2005.9.

[10] 袁文菊,孫天澤,李梅.Java虛擬機向ARM平臺的移植[J].微計算機

信息,2007.23(8-2).

[11] Sun Microsystem, Inc. Java Platform, Standard Edition 6 API

Specification,http://download.oracle.com/javase/6/docs/api/.