探索Dalvik移植技術(shù)秘密所在
其實(shí)Dalvik是基于寄存器，而JVM 卻是基于棧的，Dalvik移植技術(shù)可以將 Java .class 轉(zhuǎn)換成 .dex 格式. 一個(gè)dex檔通常會(huì)有多個(gè).class。由于dex有時(shí)必須進(jìn)行最佳化，會(huì)使檔案大小增加1-4倍，以O(shè)DEX結(jié)尾。）
本文檔指導(dǎo)讀者如何把Dalvik虛擬機(jī)移植到一個(gè)Linux平臺(tái)上，本文檔假定我們要移植的平臺(tái)和目前android平臺(tái)在代碼架構(gòu)上有一定的相似性，可以進(jìn)行移植。核心庫的移植核心庫的源代碼主要在Dalvik/libcore和dalvik/vm/native這兩個(gè)文件夾中。核心庫的源代碼是用C語言和C++寫成的。
因此在Linux環(huán)境下不需要更改。核心庫的代碼很多都是來自Apache Harmony項(xiàng)目，但是也有一些是來自O(shè)penSSL、zlb和ICU等項(xiàng)目，因此，為了虛擬機(jī)的運(yùn)行，這些項(xiàng)目需要被移植到新平臺(tái)上。
JNI Call Bridge 的移植DVM的運(yùn)行庫絕大部分都是用portable C編寫的，其中的一個(gè)例外是JNI call bridge。簡單來說，它的作用是把一系列的整型值轉(zhuǎn)變成各種類型的函數(shù)參數(shù)，并且調(diào)用函數(shù)。這個(gè)調(diào)用過程必須符合C函數(shù)調(diào)用的約定。
為了簡化移植，JNI Call Bridge在新平臺(tái)上通常會(huì)使用開源的FFI庫（我覺得，這種庫，大概類似于java一樣，具有通用性吧）。但是，Dalvik移植技術(shù)運(yùn)行不夠快，也沒有對(duì)平臺(tái)做專門優(yōu)化，所以，移植JNI Call Bridge首先應(yīng)該重新寫一個(gè)FFI庫。
JNI Call Bridge代碼在dalvik/vm/arch/*這個(gè)位置上，同時(shí)，基于FFI的版本（我覺得大概是在移植的時(shí)候的通用版本）在“generic”目錄下。每一種架構(gòu)都有兩個(gè)源文件，其中一個(gè)是定義了JNI Call Bridge函數(shù)，函數(shù)如下。dvmPlatformInvoke是把a(bǔ)rgv所指向的值轉(zhuǎn)化為符合C類型調(diào)用的值，而后調(diào)用我上面指出的函數(shù)，再把得到的返回值放入JValue* pReturn所指向的地方。
再用./rebuild重新生成文件，看一下在dalvik/vm/mterp/out目錄下的InterpAsm-myarch.S文件，可以看到在dvmAsmInstructionStart后面的一個(gè)單塊內(nèi)有stub函數(shù)的256個(gè)拷貝 。如果你不用匯編的話，系統(tǒng)就會(huì)一直使用stub.S。
注意一下，每一個(gè)塊開頭都有一個(gè)a.balign 64 指令。這個(gè)指令把處理程序擴(kuò)展到64個(gè)字節(jié)。同時(shí)也要注意到${opcode} text變成了操作碼的名字，它是用來調(diào)用C執(zhí)行的（就是dvmMterp_${opcode}）
stub.S的實(shí)際內(nèi)容由你自己來定義。看看armv5t或者x86項(xiàng)目實(shí)例下的entry.S和stub.S你就知道了。如果你將要移植的系統(tǒng)和我們說的有些不一樣，但大體相似，目前的大部分代碼你都可以使用，只是需要修改一下某些指令。具體可以看一下armv4t的移植你就清楚了。
該函數(shù)可能使用方法簽名來決定如何處理函數(shù)中的相關(guān)值。至于方法簽名，它是一個(gè)短小的DEX簽名，用一個(gè)字符對(duì)應(yīng)一個(gè)返回值和一個(gè)參數(shù)。而另外一個(gè)源文件（前面提過有兩個(gè)源文件）則定義了一個(gè)32位的“hint”。當(dāng)相應(yīng)的方法類型被加載時(shí)，hint值就會(huì)被計(jì)算出來。
作為“arginfo”參數(shù)進(jìn)入dvmPlatformInvoke函數(shù)，hint可以用來dvmPlatformInvoke停止例如掃面函數(shù)的返回值、總體參數(shù)的大小，以及整形參數(shù)64字節(jié)條件測(cè)試的限制等的ASCII方法簽名。（我想hint應(yīng)該是決定函數(shù)是否對(duì)返回值或者參數(shù)進(jìn)行方法簽名掃描）。
解釋器的移植Dalvik移植技術(shù)虛擬機(jī)運(yùn)行庫含有兩個(gè)解釋器，分別是標(biāo)以“移動(dòng)型”和“快速型”。移動(dòng)型主大體上就是一個(gè)C函數(shù)，在任何裝有GCC的系統(tǒng)上都應(yīng)該可以被編譯出來。（如果你的機(jī)器沒裝有GCC，那么你應(yīng)該停用“threaded”模塊，因?yàn)檫@個(gè)模塊依賴于GCC的goto語句的目錄來執(zhí)行的。不清楚的話可以查找THREADED_INTERP的定義。
快速型使用手工匯編導(dǎo)致的碎片（？？這里不懂）。如果目前系統(tǒng)里沒有解釋器可用，那么系統(tǒng)就會(huì)從C stubs中生成一個(gè)解釋器，這個(gè)解釋器運(yùn)行速度比移動(dòng)型慢了很多，說它是快速解釋器，實(shí)在是名不符實(shí)。
快速型在系統(tǒng)里是被默認(rèn)使能的，如果源代碼不支持快速型。那么該如何默認(rèn)使能移動(dòng)型呢？這可以通過dalvik.vm.execution-mode system來實(shí)現(xiàn)。例如。你打入如下一行：如果用匯編語言重寫解釋器的話，解釋器的效能應(yīng)該會(huì)有一個(gè)明顯的提高再加上相應(yīng)平臺(tái)專用架構(gòu)的優(yōu)化，dalvik可以用一個(gè)指令一次執(zhí)行完畢（？？這里也不懂）
【編輯推薦】
