Charles大學、Oracle實驗室和其他幾所大學的研究人員發佈了Renaissance，它是一個用於Java虛擬機性能測試的新基準。這個基準讓JVM開發人員能夠測量不同JVM發行版之間的性能，從而更好地理解應用程序在特定的JVM上有怎樣的表現。
Renaissance旨在對Java 8（2014）到Java 12（2019）這些版本之間發佈的併發特性進行更多的測試。這些測試在諸如DaCapo和SpecJVM2008等基準使用過的一些測試基礎上進行了擴展。總共有21個面向並行和併發的基準測試，覆蓋了Java和Scala代碼。另一個熱門的JVM基準測試是SPECJB2015，IBM使用它來演示硬件更改對Java性能的影響。
Renaissance白皮書的12位作者中，有5位與Oracle實驗室合作開發GraalVM。GraalVM是一種新的多語種虛擬機，可以在一個運行時中運行包括Java在內的多種軟件語言。GraalVM有社區版和商業企業版兩個版本。每個版本都有兩種模式：熱點模式和本機鏡像。熱點模式是在OpenJDK的HotSpot實現之後命名的，且通過Java測試兼容性工具包（JCK）的測試，完全兼容OpenJDK。GRAALVM的另一種模式（本機鏡像）將Java應用程序編譯成本機機器碼，由於一系列原因，它並不完全遵循Java SE的兼容性定義，但它可以運行符合其假設的應用程序。
來自Excelsior的高級軟件工程師Nikita Lipsky對Sun Microsystems在2004年定義的本機鏡像兼容性問題提出了質疑：“其中有一條規則要求產品的‘所有配置’都具備兼容性。我們不能使用特殊的配置來通過測試，然後鼓勵客戶使用其他實際上不兼容的配置。是的，那個把戲有人試過一次。”
InfoQ與Oracle進行了溝通，確認了在Renaissance基準中發佈的數字是在兼容HotSpot模式下生成的，因此可以用它們來與其他JVM進行比較。
總體而言，Graalvm社區版的性能與OpenJDK相當，而Graalvm企業版得分更好。在下面的圖表中，得分越高越好。
Renaissance的發佈引起了與其他Java實現的混淆，因爲他們沒有參與，也不知道基準可以測量什麼東西。與SPEC（SPEC提供了一個公平的基準線，在這個平臺上，競爭廠商達成了一致）不同，GraalVM獨自參與了Renaissance。儘管12位作者中有7位來自不同的大學，但競爭形勢並不存在。研究Shenandoah垃圾收集器的Red Hat性能專家Aleksey Shipilev說 ：“基準遊戲是關於可信度，而供應商基準則充滿了利益衝突。新的基準套件也如此，而與經過特別優化的供應商產品成果一起出現的新的基準套件就更是如此。”
Azul CTO Gil Tene解釋說：“創建‘新基準’可能並非偶然，但這也沒什麼錯。時間會告訴我們這是否是一個可以用來比較JVM性能的基準。只有當參賽者都站在同一條起跑線上，比賽纔算上是真正的比賽。如果Renaissance是一個真正的基準，那麼它將會保持不變，而不是‘自適應併發生快速變化’，從而允許其他人重現穩定的基準結果，對不同的實現進行比較。”
Shipilev指出了按照定義起始線來運行基準的困難之處，“如果說這個套件是‘開源和可更改的’，‘基準的選擇具有公性’就是不真實的，所以並不能解決當前的問題。”
查看英文原文：New Renaissance Performance Benchmark Aims to Compare JVMs