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