【正文】 vik VM 的 棧幀中沒有局部變量區(qū)與求值棧，取而代之的是一組虛擬寄存器。每個方法被調(diào)用時都會得到自己的一組虛擬寄存器。常用 v0v15這 16個，也有少數(shù)指令可以訪問 v0v255 范圍內(nèi)的 256個虛擬寄存器。與JVM相同的是，每個方法所需要的虛擬寄存器個數(shù)都能夠在編譯時確定，并且記錄在 .dex 文件里；每個寄存器都是字長 (32 位 )，相鄰的一對寄存器可用于保存 64 位數(shù)據(jù)。方法的參數(shù)按源碼中從左到右的順序保存在末尾的幾個虛擬寄存器里。與 JVM 版相比，可以發(fā)現(xiàn) Dalvik 版程序的指令數(shù)明顯減少了，數(shù)據(jù)移動次數(shù)也明顯減少了，用于保存 臨時結(jié)果的存儲單元也減少了。你可能會抱怨：上面兩個版本的代碼明明不對應(yīng)： JVM 版到 return 前完好持有 a、 b、 c三個變量的值；而 Dalvik 版到 returnvoid 前只持有 b 與 c 的值 (分別位于 v0 與 v1)，a 的值被刷掉了。但注意到 a 與 b 的特征：它們都只在聲明時接受過一次賦值，賦值的源是常量。這樣就可以對它們應(yīng)用常量傳播，將 Java 代碼 int c=(a+b)*5；替換為 Java 代碼 int c=(1+2)*5；然后可以再對 c 的初始化表達(dá)式應(yīng)用常量折疊，進(jìn)一步替換為： Java 代碼 int c=15；把變量 的每次狀態(tài)更新 (包括初始賦值在內(nèi) )稱為變量的一次 定義 (definition)，把每次訪問變量 (從變量讀取值 )稱為變量的一次 使用 (use)，則可以把代碼整理為 使用 定義鏈 (簡稱 UD 鏈， usedefine chain)。顯然，一個變量的某次定義要被使用過才有意義。上面的例子經(jīng)過常量傳播與折疊后，我們可以分析得知變量 a、 b、 c 都只被定義而沒有被使用。于是它們的定義就成為了無用代碼 (dead code)，可以安全的被消除。上面一段的分析用一句話描述就是：由于 foo()里沒有產(chǎn)生外部可見的副作用，所以foo()的整個方法體都可以被優(yōu)化為空。經(jīng)過 dx工具處理后， Dalvik 版程序相對 JVM 版確實是稍微優(yōu)化了一些，不過沒有影響程序的語義，程序的正確性是沒問題的。這是其一。其二是 Dalvik 版代碼只要多分配一個虛擬寄存器就能在returnvoid 前同時持有 a、 b、 c三個變量的值，指令幾乎沒有變化： Dalvik bytecode 代碼 0000： const/4 v0,int1//10001： const/4 v1,int2//20212： addint v2,v0,v10004： mulint/lit8 v2,v2,int5//050006： returnvoid 這樣比原先的版本多使用了一個虛擬寄存器，指令方面也多用了一個單元 (addint 指令占 2單元 )；但指令的條數(shù)沒變，仍然是 5條，數(shù)據(jù)移動的次數(shù)也沒變。題外話 1： Dalvik VM 是基于寄存器的， x86 也是基于寄存器的，但兩者的 寄存器 卻相當(dāng)不同：前者的寄存器是每個方法被調(diào)用時都有自己一組私有的，后者的寄存器則是全局的。也就是說，Dalvik VM 字節(jié)碼中不用擔(dān)心保護(hù)寄存器的問題，某個方法在調(diào)用了別的方法返回過來后自己的寄存器的值肯定跟調(diào)用前一樣。 而 x86 程序在調(diào)用函數(shù)時要考慮清楚 calling convention，調(diào)用方在調(diào)用前要不要保護(hù)某些寄存器的當(dāng)前狀態(tài)，還是說被調(diào)用方會處理好這些問題，麻煩事不少。 Dalvik VM 這種虛擬寄存器讓人想起一些實際處理器的 寄存器窗口 ，例如 SPARC 的 Register Windows 也是保證每個函數(shù)都覺得自己有 私有的一組寄存器 ，減輕了在代碼里處理寄存器保護(hù)的麻煩 扔給硬件和操作系統(tǒng)解決了。題外話 2： Dalvik的 .dex 文件在未壓縮狀態(tài)下的體積通常比同等內(nèi)容的 .jar 文件在 deflate 壓縮后還要小。但 光從字節(jié)碼看， Java 字節(jié)碼幾乎總是比 Dalvik 的小，那 .dex 文件的體積是從哪里來減出來的呢 ?這主要得益與 .dex 文件對常量池的壓縮，一個 .dex 文件中所有類都共享常量池，使得相同的字符串、相同的數(shù)字常量等都只出現(xiàn)一次，自然能大大減小體積。相比之下， .jar 文件中每個類都持有自己的常量池，諸如 Ljava/lang/Object； 這種常見的字符串會被重復(fù)多次。 Sun自己也有進(jìn)一步壓縮 JAR 的工具， Pack200，對應(yīng)的標(biāo)準(zhǔn)是 JSR 200。它的主要應(yīng)用場景是作為 JAR 的網(wǎng)絡(luò)傳輸格式，以更高的壓縮比來減 少文件傳輸時間。在官方文檔提到了 Pack200 所用到的壓縮技巧， JDK Documentation 寫道 Pack200 works most efficiently on Java class uses several techniques to efficiently reduce the size of JAR files： It merges and sorts the constantpool data in the class files and colocates them in the removes redundant class stores internal data use delta and variable length chooses optimum coding types for secondary .dex 文件與 Pack200 采用了一些相似的減小體積的方法。很可惜目前還沒有正式發(fā)布的 JVM 支持直接加載 Pack200 格式 的歸檔，畢竟網(wǎng)絡(luò)傳輸才是 Pack200 最初構(gòu)想的應(yīng)用場景。再次提醒注意，上面的描述是針對概念上的 JVM 與 Dalvik VM，而不是針對它們的具體實現(xiàn)。實現(xiàn) VM時可以采用許多優(yōu)化技巧去減少性能損失，使得實際的運行方式與概念中的不完全相符，只要最終的運行結(jié)果滿足原本概念上的 VM所實現(xiàn)的語義就行。 ===上面 簡單 的提了些討論點，不過還沒具體到 JavaScript 引擎，抱歉。弄得太長了，只好在這里先拆分一次…有些東西想寫的，洗個澡又忘記了。等想起來再補(bǔ)充orz簡單 是相對于實際應(yīng)該掌握的信息量而言。上面寫的都還 沒撓上癢癢，心虛。 Anyway。根據(jù)拆分的現(xiàn)狀，下一篇應(yīng)該是討論動態(tài)語言與編譯的問題，然后再下一篇會看看解釋器的演化方法，再接著會看看 JavaScript 引擎的狀況(主要針對 V8 和 Nitro，也會談?wù)?Tamarin。就不討論 JScript 了 )。關(guān)于推薦資料，在 我的收藏 的 virtual machine 標(biāo)簽里就有不少值得一讀的資料。如果只是對 JavaScript 引擎相關(guān)感興趣的話也可以選著讀些。我的收藏里還有v8和 tamarin 等標(biāo)簽的，資料有的是 ^^能有耐心讀到結(jié)尾的同學(xué)們，歡迎提出意見和建議，以及指出文 中的錯漏 ^_^不像抓到蟲就給美分的大師，我沒那種信心…錯漏難免，我也需要進(jìn)一步學(xué)習(xí)。拜托大家了 ~，加上JavaEye 的帶寬也不是無限的…所以拜托不要直接鏈接這帖里的圖 (_ _)有需要原始圖片的可以跟我聯(lián)系。我是畫成多幀 PNG 然后轉(zhuǎn)換為 GIF發(fā)出來的。上面的 PNG 圖片都還保留有原始的圖層信息，要拿去再編輯也很方便 ^^更新 1：原本在樹遍歷解釋器圖解的小節(jié)中，我用的是這幅圖：其實上圖畫得不準(zhǔn)確， a、b、 c 的右值不應(yīng)該畫在節(jié)點上的；節(jié)點應(yīng)該只保存了它們的左值才對，要獲取對應(yīng)的右值就要查詢變量表 。我修改了圖更新到正文了。原本的圖里對 i的賦值看起來很奇怪，就像是遍歷過程經(jīng)過了兩次 i 節(jié)點一般，而事實不是那樣的。 發(fā)表于 @2021年 04月 27日 00： 15： 00||| 特別聲明： 1：資料來源于互聯(lián)網(wǎng)，版權(quán)歸屬原作者 2：資料內(nèi)容屬于網(wǎng)絡(luò)意見，與本賬號立場無關(guān) 3：如有侵權(quán)，請告知，立即刪除。