1.4 Java虛擬機(jī)發(fā)展史

上一節(jié)我們從整個Java技術(shù)的角度觀察了Java 技術(shù)的發(fā)展，許多Java程序員都會潛意識地把它與Sun公司的HotSpot虛擬機(jī)等同看待，也許還有一些程序員會注意到BEA.JRockit和IBM J9，但對JVM的認(rèn)識不僅僅只有這些。從1996年初Sun公司發(fā)布的JDK1.0中所包含的SunClassicVM到今天，曾經(jīng)涌現(xiàn)、湮滅過許多或經(jīng)典或優(yōu)秀或有特色的虛擬機(jī)實(shí)現(xiàn)，在這一- 節(jié)中，我們先暫且把代碼與技術(shù)放下， 一起來回顧- -下Java 虛擬機(jī)家族的發(fā)展軌跡和歷史變遷。

1.4.1 Sun Classic / Exact VM以今天的視角來看，Sun Classic VM的技術(shù)可能很原始，這款虛擬機(jī)的使命也早已終結(jié)。

但僅憑它“世界上第-款商用Java虛擬機(jī)”的頭銜，就足夠有讓歷史記住它的理由。1996年1月23日，Sun公司發(fā)布JDK 1.0，Java 語言首次擁有了商用的正式運(yùn)行環(huán)境，這個JDK中所帶的虛擬機(jī)就是ClassicVM。這款虛擬機(jī)只能使用純解釋器方式來執(zhí)行Java代碼，如果要使用JIT編譯器，就必須進(jìn)行外掛。但是假如外掛了JIT編譯器，JIT編譯器就完全接管了虛擬機(jī)的執(zhí)行系統(tǒng)，解釋器便不再工作了。用戶在這款虛擬機(jī)上執(zhí)行java-version命令，將會看到類似下面這行輸出:java version "1.2.2"Classic VM (build JDK-1.2.2-001. green threads, sunwjit)其中的“sunwjit"就是Sun提供的外掛編譯器，其他類似的外掛編譯器還有SymantecJIT和shuJIT等。由于解釋器和編譯器不能配合工作，這就意味著如果要使用編譯器執(zhí)行，編譯器就不得不對每-一個方法、每一行代碼都進(jìn)行編譯，而無論它們執(zhí)行的頻率是否具有編譯的價值。基于程序響應(yīng)時間的壓力，這些編譯器根本不敢應(yīng)用編譯耗時稍高的優(yōu)化技術(shù)，
因此這個階段的虛擬機(jī)即使用了JIT編譯器輸出本地代碼，執(zhí)行效率也和傳統(tǒng)的C/C++程序有很大差距，“Java 語言很慢”的形象就是在這時候開始在用戶心中樹立起來的。

Sun的虛擬機(jī)團(tuán)隊(duì)努力去解決ClassicVM所面臨的各種問題，提升運(yùn)行效率。在JDK1.2時，曾在Solaris平臺上發(fā)布過一-款名為ExactVM的虛擬機(jī)，它的執(zhí)行系統(tǒng)已經(jīng)具備現(xiàn).代高性能虛擬機(jī)的雛形:如兩級即時編譯器、編譯器與解釋器混合工作模式等。ExactVM因它使用準(zhǔn)確式內(nèi)存管理( Exact Memory Management，也可以叫Non-Conservative/AccurateMemory Management)而得名，即虛擬機(jī)可以知道內(nèi)存中某個位置的數(shù)據(jù)具體是什么類型。譬如內(nèi)存中有一個32位的整數(shù)123456，它到底是-一reference 類型指向123456 的內(nèi)存地址還是一一個數(shù)值為123456的整數(shù)，虛擬機(jī)將有能力分辨出來，這樣才能在GC (垃圾收集)的時候準(zhǔn)確判斷堆上的數(shù)據(jù)是否還可能被使用。由于使用了準(zhǔn)確式內(nèi)存管理，ExactVM可以拋棄以前Classic VM基于handler的對象查找方式(原因是進(jìn)行GC后對象將可能會被移動位置，如果將地址為123456的對象移動到654321，在沒有明確信息表明內(nèi)存中哪些數(shù)據(jù)是
reference的前提下，虛擬機(jī)是不敢把內(nèi)存中所有為123456的值改成654321的，所以要使用句柄來保持reference值的穩(wěn)定)，這樣每次定位對象都少了一次間接查找的開銷，提升執(zhí)行性能。雖然Exact VM的技術(shù)相對Classic VM來說先進(jìn)了許多，但是在商業(yè)應(yīng)用上只存在了很短暫的時間就被更為優(yōu)秀的HotSpotVM所取代，甚至還沒有來得及發(fā)布Windows和Linux平臺下的商用版本。而ClassicVM的生命周期則相對長了許多，它在JDK1.2之前是SunJDK中唯- -的虛擬機(jī)， 在JDK 1.2時，它與HotSpot VM并存，但默認(rèn)使用的是Classic VM(用戶可用java-hotspot參數(shù)切換至HotSpot VM)，而在JDK 1.3 時，HotSpot VM成為默認(rèn)虛擬機(jī)，但Classic VM仍作為虛擬機(jī)的“備用選擇”發(fā)布(使用java-classic參數(shù)切換)，直到JDK1.4的時候，ClassicVM才完全退出商用虛擬機(jī)的歷史舞臺，與ExactVM--起進(jìn)人了Sun Labs Research VM之中。

1.4.2 Sun HotSpot VM

提起HotSpotVM，相信所有Java程序員都知道，它是SunJDK和OpenJDK中所帶的虛擬機(jī)，也是目前使用范圍最廣的Java虛擬機(jī)。但不一定所有人都知道的是，這個目前看起來“血統(tǒng)純正”的虛擬機(jī)在最初并非由Sun公司開發(fā)，而是由一-家名為“Longview?
Technologies"的小公司設(shè)計的;甚至這個虛擬機(jī)最初并非是為Java語言而開發(fā)的，它來源于Strongalk VM，而這款虛擬機(jī)中相當(dāng)多的技術(shù)又是來源于- - 款支持Self語言實(shí)現(xiàn)“達(dá)到C語言50%以上的執(zhí)行效率”的目標(biāo)而設(shè)計的虛擬機(jī)，Sun公司注意到了這款虛擬機(jī)在JIT編譯.上有許多優(yōu)秀的理念和實(shí)際效果，在1997年收購了Longview Technologies 公司，從而獲得了HotSpot VM。

HotSpotVM既繼承了Sun之前兩款商用虛擬機(jī)的優(yōu)點(diǎn)(如前面提到的準(zhǔn)確式內(nèi)存管理)，也有許多自己新的技術(shù)優(yōu)勢，如它名稱中的HotSpot指的就是它的熱點(diǎn)代碼探測技術(shù)(其實(shí)兩個VM基本上是同時期的獨(dú)立產(chǎn)品，HotSpot 還稍早- -些，HotSpot 一開始就是準(zhǔn)確式GC，而Exact VM之中也有與HotSpot幾乎一樣的熱點(diǎn)探測。為了Exact VM和HotSpotVM哪個成為Sun主要支持的VM產(chǎn)品，在Sun公司內(nèi)部還有過爭論，HotSpot打敗Exact并不能算技術(shù)上的勝利)，HotSpot VM的熱點(diǎn)代碼探測能力可以通過執(zhí)行計數(shù)器找出最具有編譯價值的代碼，然后通知JIT編譯器以方法為單位進(jìn)行編譯。如果--個方法被頻繁調(diào)用，或方法中有效循環(huán)次數(shù)很多，將會分別觸發(fā)標(biāo)準(zhǔn)編譯和OSR (棧.上替換)編譯動作。通過編譯器與解釋器恰當(dāng)?shù)貐f(xié)同工作，可以在最優(yōu)化的程序響應(yīng)時間與最佳執(zhí)行性能中取得平衡，而且無須等待本地代碼輸出才能執(zhí)行程序，即時編譯的時間壓力也相對減小，這樣有助于引人更多的代碼優(yōu)化技術(shù)，輸出質(zhì)量更高的本地代碼。
在2006年的JavaOne大會上，Sun公司宣布最終會把Java開源，并在隨后的--年，陸續(xù)將JDK的各個部分(其中當(dāng)然也包括了HotSpot VM)在GPL協(xié)議下公開了源碼，并在此基礎(chǔ)上建立了OpenJDK。這樣，HotSpot VM便成為了Sun JDK和OpenJDK兩個實(shí)現(xiàn)極度接近的JDK項(xiàng)目的共同虛擬機(jī)。在2008年和2009年，Oracle 公司分別收購了BEA公司和Sun公司，這樣Oracle就同
時擁有了兩款優(yōu)秀的Java虛擬機(jī): JRockit VM和HotSpot VM。Oracle 公司宣布在不久的將來(大約應(yīng)在發(fā)布JDK 8的時候)會完成這兩款虛擬機(jī)的整合工作，使之優(yōu)勢互補(bǔ)。整合的方式大致上是在HotSpot的基礎(chǔ)上，移植JRockit的優(yōu)秀特性，譬如使用JRockit 的垃圾回收器與MissionControl服務(wù)，使用HotSpot的JIT編譯器與混合的運(yùn)行時系統(tǒng)。

1.4.3 Sun Mobile-Embedded VM / Meta-Circular VM

Sun公司所研發(fā)的虛擬機(jī)可不僅有前面介紹的服務(wù)器、桌面領(lǐng)域的商用虛擬機(jī)，除此之外，Sun 公司面對移動和嵌人式市場，也發(fā)布過虛擬機(jī)產(chǎn)品，另外還有一-類虛擬機(jī)，在設(shè)計之初就沒抱有商用的目的，僅僅是用于研究、驗(yàn)證某種技術(shù)和觀點(diǎn)，又或者是作為一.些規(guī)范的標(biāo)準(zhǔn)實(shí)現(xiàn)。這些虛擬機(jī)對于大部分不從事相關(guān)領(lǐng)域開發(fā)的Java程序員來說可能比較陌生。Sun公司發(fā)布的其他Java虛擬機(jī)有:
(1) KVM
KVM中的K是“Kilobyte"的意思，它強(qiáng)調(diào)簡單、輕量、高度可移植，但是運(yùn)行速度比較慢。在Android、iOS等智能手機(jī)操作系統(tǒng)出現(xiàn)前曾經(jīng)在手機(jī)平臺上得到非常廣泛的應(yīng)用。

(2) CDC/CLDC HotSpot Implementation
CDC/CLDC全稱是Connected (Limited) Device Configuration，在JSR-139/JSR-218規(guī)范中進(jìn)行定義，它希望在手機(jī)、電子書、PDA等設(shè)備上建立統(tǒng)一的Java編程接口，而CDC-HI VM和CLDC-HI VM則是它們的一-組參考實(shí)現(xiàn)。CDC/CLDC是整個Java ME的重要支柱，但從目前Android和iOS二分天下的移動數(shù)字設(shè)備市場看來，在這個領(lǐng)域中，Sun 的虛擬機(jī)所面臨的局面遠(yuǎn)不如服務(wù)器和桌面領(lǐng)域樂觀。
(3) Squawk VM
Squawk VM由Sun公司開發(fā)，運(yùn)行于Sun SPOT (Sun Small Programmable Object Technology,- -種手持的WiFi 設(shè)備)，也曾經(jīng)運(yùn)用于Java Card.這是-一個Java代碼比重很高的嵌人式虛擬機(jī)實(shí)現(xiàn)，其中諸如類加載器、字節(jié)碼驗(yàn)證器、垃圾收集器、解釋器、編譯器和線程調(diào)度都是 Java語言本身完成的，僅僅靠C語言來編寫設(shè)備I/O和必要的本地代碼。

(4) JavaInJava
JavalnJava是Sun公司于1997年~ 1998 年間研發(fā)的一個實(shí)驗(yàn)室性質(zhì)的虛擬機(jī)，從名字就可以看出，它試圖以Java語言來實(shí)現(xiàn)Java語言本身的運(yùn)行環(huán)境，既所謂的“元循環(huán)”(Meta-Circular，是指使用語言自身來實(shí)現(xiàn)其運(yùn)行環(huán)境)。它必須運(yùn)行在另外一個宿主虛擬機(jī)之上，內(nèi)部沒有JIT編譯器，代碼只能以解釋模式執(zhí)行。在20世紀(jì)末主流Java虛擬機(jī)都未能很好解決性能問題的時代，開發(fā)這種項(xiàng)目，其執(zhí)行速度可想而知。
(5) Maxine VM
Maxine VM和上面的JavalnJava非常相似，它也是一個幾乎全部以Java代碼實(shí)現(xiàn)(只有用于啟動JVM的加載器使用C語言編寫)的元循環(huán)Java虛擬機(jī)。這個項(xiàng)目于2005年開始，到現(xiàn)在仍然在發(fā)展之中，比起JavaInJava，Maxine VM就顯得“靠譜”很多，它有先進(jìn)
的JIT編譯器和垃圾收集器(但沒有解釋器)，可在宿主模式或獨(dú)立模式下執(zhí)行，其執(zhí)行效率.已經(jīng)接近了HotSpot Client VM的水平。

1.4.4 BEA JRockit I IBM J9 VM

前面介紹了Sun公司的各種虛擬機(jī)，除了Sun公司以外，其他組織、公司也研發(fā)過不少虛擬機(jī)實(shí)現(xiàn)，其中規(guī)模最大、最著名的就是BEA和IBM公司了。

JRockit VM曾經(jīng)號稱“世界上速度最快的Java 虛擬機(jī)”(廣告詞，貌似J9 VM也這樣說過)，它是BEA公司在2002年從Appeal Virtual Machines公司收購的虛擬機(jī)。BEA公司將其發(fā)展為一款專門為服務(wù)器硬件和服務(wù)器端應(yīng)用場景高度優(yōu)化的虛擬機(jī)，由于專注于服務(wù)器端應(yīng)用，它可以不太關(guān)注程序啟動速度，因此JRockit內(nèi)部不包含解析器實(shí)現(xiàn)，全部代碼都靠即時編譯器編譯后執(zhí)行。除此之外，JRockit 的垃圾收集器和MissionControl服務(wù)套件等部分的實(shí)現(xiàn)，在眾多Java虛擬機(jī)中也一- 直處于領(lǐng)先水平。IBMJ9VM并不是IBM公司唯一的Java虛擬機(jī)，不過是目前其主力發(fā)展的Java虛擬機(jī)。IBM J9 VM原本是內(nèi)部開發(fā)代號，正式名稱是"IBM Technology for Java VirtualMachine"，簡稱IT4J,只是這個名字太拗口了一點(diǎn)，普及程度不如J9。J9 VM最初是由IBMOttawa實(shí)驗(yàn)室一個 名為SmallTalk的虛擬機(jī)擴(kuò)展而來的，當(dāng)時這個虛擬機(jī)有一一個 bug是由8k值定義錯誤引起的，工程師花了很長時間終于發(fā)現(xiàn)并解決了這個錯誤，此后這個版本的虛擬機(jī)就稱為K8了，后來擴(kuò)展出支持Java的虛擬機(jī)就被稱為J9了。與BEA JRockit專注于服務(wù)器端應(yīng)用不同，IBM J9的市場定位與Sun HotSpot比較接近，它是- - 款設(shè)計上從服務(wù)器端到;桌面應(yīng)用再到嵌人式都全面考慮的多用途虛擬機(jī)，J9的開發(fā)其的是作為IBM公司各種Javaifi產(chǎn)品的執(zhí)行平臺，它的主要市場是和IBM產(chǎn)品_(如IBMWebSphere等):搭配以及在IBMAIX和z/OS這些平臺上部署Java應(yīng)用。

1.4.5 Azul:VM /BEA Liquid:VM

的我們平時所提及的“高性能Java虛擬機(jī)”一般是指HotSpot、JRockit、J9這類在通用平rhe臺上運(yùn)行的商用虛擬機(jī)，但其實(shí)AzulVM和BEALiquidVM這類特定硬件平臺專有的虛擬機(jī)才是“高性能”的武器。Azul VM是Azul Systems公司在HotSpot基礎(chǔ)E進(jìn)行大量改進(jìn)，運(yùn)行于Azul Systems公司的專有硬件Vega系統(tǒng)上的Java虛擬機(jī)，每個AzulVM實(shí)例都可以管理至少數(shù)十個CPU和數(shù)百GB內(nèi)存的硬件資源，并提供在巨大內(nèi)存范圍內(nèi)實(shí)現(xiàn)可控的GC時間的垃圾收集器、為專有硬件優(yōu)化的線程調(diào)度等優(yōu)秀特性。在2010年，Azul Systems公司開始從硬件轉(zhuǎn)向軟件，發(fā)布了自己的Zing JVM，可以在通用x86平臺上提供接近于Vega系統(tǒng)的特性。Liquid VM即是現(xiàn)在的JRockit VE ( Virtual Edition)，它是BEA公司開發(fā)的，可以直接運(yùn)行在自家Hypervisor系統(tǒng)上的JRockit VM的虛擬化版本，Liquid VM不需要操作系統(tǒng)的支持，或者說它自己本身實(shí)現(xiàn)了一個專用操作系統(tǒng)的必要功能，如文件系統(tǒng)、網(wǎng)絡(luò)支持等。由虛擬機(jī)越過通用操作系統(tǒng)直接控制硬件可以獲得很多好處，如在線程調(diào)度時，不需要再進(jìn)行內(nèi)核態(tài)/用戶態(tài)的切換等，這樣可以最大限度地發(fā)揮硬件的能力，提升Java程序的執(zhí)行性能。

1.4.6 Apache Harmony / Google Android Dalvik VM

這節(jié)介紹的HarmonyVM和DalvikVM只能稱做“虛擬機(jī)”，而不能稱做“Java虛擬機(jī)”，但是這兩款虛擬機(jī)(以及所代表的技術(shù)體系)對最近幾年的Java世界產(chǎn)生了非常大的影響和挑戰(zhàn)，甚至有些悲觀的評論家認(rèn)為成熟的Java生態(tài)系統(tǒng)有崩潰的可能ApacheHarmony是-一個Apache軟件基金會旗下以ApacheLicense協(xié)議開源的實(shí)際兼容于JDK 1.5和JDK 1.6 的Java程序運(yùn)行平臺，這個介紹相當(dāng)拗口。它包含自己的虛擬機(jī)和Java庫，用戶可以在上面運(yùn)行Eclipse、Tomcat、 Maven等常見的Java程序，但是它沒有通過TCK認(rèn)證，所以我們不得不用那么一長串拗口的語言來介紹它，而不能用一句“Apache的JDK”來說明。如果一個公司要宣布自己的運(yùn)行平臺“兼容于Java語言”，那就必須要通過TCK (Technology Compatibility Kit)的兼容性測試。Apache 基金會曾要求Sun公司提
供TCK的使用授權(quán)，但是一-直遭到拒絕，直到Oracle公司收購了Sun公司之后，雙方關(guān)系越鬧越僵，最終導(dǎo)致Apache憤然退出JCP (Java Community Process) 組織，這是目前為止.Java社區(qū)最嚴(yán)重的- -次“分裂”。在Sun將JDK開源形成OpenJDK之后，Apache Harmony開源的優(yōu)勢被極大地削弱，甚至連Harmony項(xiàng)目的最大參與者IBM公司也宣布辭去Harmony項(xiàng)目管理主席的職位，并參與OpenJDK項(xiàng)目的開發(fā)。雖然Harmony沒有經(jīng)過真正大規(guī)模的商業(yè)運(yùn)用，但是它的許多代碼(基本.上是Java庫部分的代碼)被吸納進(jìn)IBM的JDK7實(shí)現(xiàn)及GoogleAndroidSDK之中，尤其是對Android的發(fā)展起到了很大的推動作用。說到Android,這個時下最熱門的移動數(shù)碼設(shè)備平臺在最近幾年間的發(fā)展過程中所取得的成果已經(jīng)遠(yuǎn)遠(yuǎn)超越了JavaME在過去十多年所獲得的成果Android讓Java語言真正走進(jìn)了移動數(shù)碼設(shè)備領(lǐng)域，只是走的并非Sun公司原本想象的那- - 條路。Dalvik VM是Android平臺的核心組成部分之一，它的名字來源于冰島-一個名為Dalvik的小漁村。Dalvik VM并不是-一個Java虛擬機(jī)，它沒有遵循Java虛擬機(jī)規(guī)范，不能直接執(zhí)行Java的Class文件，使用的是寄存器架構(gòu)而不是JVM中常見的棧架構(gòu)。但是它與Java又有著千絲萬縷的聯(lián)系，它執(zhí)行的dex(DalvikExecutable)文件可以通過Class文件轉(zhuǎn)化而來，使用Java語法編寫應(yīng)用程序，可以直接使用大部分的Java API等。目前Dalvik VM隨著Android一起處于迅猛發(fā)展階段，在Android 2.2中已提供即時編譯器實(shí)現(xiàn)，在執(zhí)行性能上有了很大的提高。

1.4.7 Microsoft JVM及其他

在十幾年的Java虛擬機(jī)發(fā)展過程中，除去上面介紹的那些被大規(guī)模商業(yè)應(yīng)用過的Java虛擬機(jī)外，還有許多虛擬機(jī)是不為人知的或者曾經(jīng)“絢麗”過但最終湮滅的。我們以其中微軟公司的JVM為例來介紹- -下。也許Java程序員聽起來可能會覺得驚訝，微軟公司曾經(jīng)是Java技術(shù)的鐵桿支持者(也必須承認(rèn)，與Sun公司爭奪Java的控制權(quán)，令Java從跨平臺技術(shù)變?yōu)榻壎ㄔ赪indows上的技術(shù)是微軟公司的主要目的)。在Java語言誕生的初期(1996年~ 1998年，以JDK 1.2 發(fā)布為分界)，它的主要應(yīng)用之-一是在瀏覽器中運(yùn)行Java Applets程序，微軟公司為了在IE3中支持Java Applets應(yīng)用而開發(fā)了自己的Java虛擬機(jī)，雖然這款虛擬機(jī)只有Windows平臺的版本，卻是當(dāng)時Windows下性能最好的Java虛擬機(jī)，它在1997年和1998年連續(xù)兩年獲得了.《PC Magazine》雜志的“編輯選擇獎”。但好景不長，在1997年10月，Sun 公司正式以侵犯商標(biāo)、不正當(dāng)競爭等罪名控告微軟公司，在隨后對微軟公司的壟斷調(diào)查之中，這款虛擬機(jī)也曾作為證據(jù)之一被呈送法庭。這場官司的結(jié)果是微軟公司賠償2000萬美金給Sun公司(最終微軟公司因壟斷賠償給Sun公司的總金額高達(dá)10億美元)，承諾終止其Java虛擬機(jī)的發(fā)展，并逐步在產(chǎn)品中移除Java虛擬機(jī)相關(guān)功能。具有諷刺意味的是，到最后在WindowsXPSP3中Java虛擬機(jī)被完全抹去的時候，Sun公司卻又到處登報希望微軟公司不要這樣做。WindowsXP高級產(chǎn)品經(jīng)理Jim Cullinan稱:“我們花費(fèi)了3年的時間和Sun打官司，當(dāng)時他們試圖阻止我們在Windows中支持Java，現(xiàn)在我們這樣做了，可他們又在抱怨，這太具有諷刺意味了。”我們試想一下，如果當(dāng)年Sun公司沒有起訴微軟公司，微軟公司繼續(xù)保持著對Java，技術(shù)的熱情，那Java的世界會變得怎么樣呢? .NET 技術(shù)是否會發(fā)展起來?但歷史是沒有假設(shè)的。其他在本節(jié)中沒有介紹到的Java虛擬機(jī)還有(當(dāng)然，應(yīng)該還有很多筆者所不知道的):

口? ? JamVM。
口? ? cacaovm。
口? ? SableVM。
口? ? Kaffe。
口? ?Jelatine JVM。
口? ?NanoVM。
口? ?MRP。
口? ?Moxie JVM.
口? ?Jikes RVM。

?

?

?

?

"HotRockit" 項(xiàng)目的相關(guān)介紹: http://hirt.se/presentations/WhatToExpect.ppt.

總結(jié)

以上是生活随笔為你收集整理的《深入理解java虚拟机》第1章 走近Java的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。