ARM9平臺上KVM移植的研究和實現

易佳望 王斌 肖暉 胡海

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

關鍵詞： 移動應用開發； J2ME； CLDC； KVM移植

中圖分類號：TP399文獻標志碼：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 引言

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

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

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

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

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

1 KVM的代碼執行機制

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

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

[Java源程序

(*.java)][Java字節碼

(*.class)][Java API類庫

(*.class)][Java虛擬機

(內含interpreter)][操作系統及電腦硬件] [Bytecode結構] [編譯] [運行] [翻譯成本地代碼執行][加載及校驗][加載及校驗]

圖1JVM的代碼執行機制

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

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

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

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

[MyApp.Java][javac] [MyApp.class][preverifier] [預驗證過的

MyApp.class][verifier] [interpreter][KVM] [下載到目標設備][預驗證過的

核心API類庫

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

圖2KVM的代碼執行機制

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

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

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

2 CLDC參考實現

移植所用的KVM源碼是來自SUN公司的CLDC 1.1參考實現。表1中描述了該CLDC 1.1參考實現源碼包中的目錄結構[4]。

表1CLDC 1.1參考實現的目錄結構

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

3 CLDC參考實現的build過程

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

用于源碼build的Makefile文件根據源碼目錄的層次結構相應地被組織成一個層次結構。主Makefile文件放在build目錄中，由這里跳轉去執行其它Makefile文件。在build目錄中，根據目標平臺上操作系統的不同類型分別對應有不同的主Makefile文件。

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

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

[編譯生成preverify工具

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

在壓縮得到class.zip文件

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

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

nativeFunctionTableUnix.c

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

編譯為*.o目標文件][將api類庫對應的兩個.c文件

編譯為兩個.o目標文件][將kvm的*.o文件和api類庫對應的兩個.o文件

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

圖3以ARM+Linux為目標平臺的build過程

4 CLDC參考實現的源碼編譯

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

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

ifeq($(GCC),true)

CC=arm-linux-gcc

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

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

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

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

下面我們對CLDC源碼編譯過程中各階段產生的errors和warnings進行分析，并給出適當的解決方法。

4.1 編譯生成preverify工具

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

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

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

內嵌函數exit的不兼容隱式聲明&添加語句“#include”&warning 2：

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

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

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

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

因為iconv函數會修改第2個參數inbuf和第4個參數outbuf指針所指向的地方，而源碼中傳遞給iconv函數的第2個參數from是指向const char類型的，其值是不能改變的，所以有警告。

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

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

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

4.2 編譯和預驗證api類庫

在使用Javac編譯api目錄下的Java源文件時，編譯產生的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需要將源程序文本文件從原編碼格式統一轉換為Java內部默認的Unicode格式。

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

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

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

4.3 編譯生成jcc工具

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

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

⑴ warning 1：同表4中的warning。

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

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

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

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

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

JDK1.5之后，'enum'是關鍵詞，不能被用作標識符&在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源文件時，編譯產生的errors & warnings及其解決方法可以見表6。

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

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

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

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

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

_FPU_EXTENDED和

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

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

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

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

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

⑷ warning 3：略。

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

5 移植結果測試

移植測試采用的目標開發板平臺為S3C2440+Embedded Linux 2.6.32.2。

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

編寫一個“Hello World！”Java源程序，編譯和預驗證時指定-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，指定源碼版本。

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

圖4KVM移植結果測試

6 結束語

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

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

參考文獻：

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

系統應用,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虛擬機性能優化

技術研究[J].計算機應用研究,2007.24(5).

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

2007.

[9] 葉磊,陳榕,趙岳松.KVM在基于構件的嵌入式操作系統上的移植和

研究[J].計算機應用研究,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/.