紅帽高級總監談OpenJDK的未來:Java的未來從未如此光明

隨着Java 11的發佈,Java最終完成了到OpenJDK一等項目的過渡。使用專有OracleJDK二進制文件的日子已經結束了。對Java開放性和免費的關注自然而然將Oracle以外的公司的貢獻帶入到了聚光燈下。最近,InfoQ採訪了Red Hat中間件產品管理高級總監Rich Sharples,討論了OpenJDK和Red Hat的參與情況。

InfoQ:在很早之前,Red Hat就一直是OpenJDK的貢獻者。你能談談你和這個項目之間的歷史淵源嗎?

Rich Sharples:Red Hat於2007年11月5日宣佈與Sun Microsystems達成廣泛的貢獻者協議。這項協議包括了Red Hat工程師參與Sun領導的所有開源項目。同時,Red Hat簽署了Sun的OpenJDK Community TCK許可協議,成爲第一家簽署該協議的主要軟件供應商。Red Hat還與Sun分享開發人員的貢獻,共同創建OpenJDK社區以及促進創新。Red Hat是繼Oracle之後OpenJDK的最大貢獻者之一。

Red Hat通過上述舉措深度參與Java生態系統,這在Red Hat收購JBoss之後的時期起到了非常重要的作用。2009年,Sun被Oracle收購,Sun和Red Hat之間已經建立起來的關係在Oracle眼皮底下繼續發展。

自2007年加入OpenJDK項目以來,Red Hat持續爲上游OpenJDK社區做出貢獻,並將OpenJDK打包進了Red Hat Enterprise Linux中。Red Hat曾在2013年領導OpenJDK 6的開發(支持到2016年),並在2015年接管了OpenJDK 7的管理權。Andrew Haley在Red Hat開發者博客的這篇文章中詳細介紹了我們接管的工作。

和OpenJDK 7一樣,OpenJDK 6被打包進了Red Hat Enterprise Linux 5、6和7當中。Red Hat Enterprise Linux 6和7還支持OpenJDK 8。Red Hat Enterprise Linux 7.6支持OpenJDK 11。除了爲一系列Red Hat Enterprise Linux版本提供支持外,我們還一直爲OpenJDK發行版提供全生命週期支持。

最近,OpenJDK 7的生命週期被延長至2020年6月,OpenJDK 8被延長至2023年6月,旨在爲用戶提供足夠的時間將工作負載遷移到OpenJDK 11。

除了爲Red Hat Enterprise Linux上的OpenJDK提供發行和生命週期支持外,Red Hat的開源Java中間件產品也支持Red Hat Enterprise Linux的OpenJDK,讓戶能夠從單個供應商獲得從操作系統到應用程序服務的完整技術棧支持。其他的Red Hat產品也運行在OpenJDK上。我們是一個爲全球依賴開源軟件運行應用程序工作負載的客戶提供支持的領先廠商。

InfoQ:我們來談談目前的狀況。目前看來,Red Hat有多少工程師正在參與OpenJDK的工作(全職和兼職)?主要參與哪些方面的工作?

Sharples:出於政策方面的考慮,我們不方便公開Red Hat在特定項目上的投入情況。

Red Hat Java平臺團隊首席工程師Andrew Haley多年來一直是OpenJDK管理委員會的成員,同時也是AArch64移植項目的負責人。此外,Andrew還是JDK 7項目的負責人,並打算在Oracle支持週期結束後申請負責OpenJDK 8和11的開發。

InfoQ:在具體技術方面,你認爲Red Hat在哪些領域做出了最大的貢獻?哪些技術組件可以體現Red Hat的強大領導力?

Sharples:Red Hat領導了64位ARMv8的移植,即OpenJDK的AArch64項目,並將它併入上游的OpenJDK項目中。目前,我們正在與OpenJDK社區合作開發一個新的超低停頓時間的垃圾回收器,名字叫作Shenandoah,它處於OpenJDK主線之外——但在Red Hat Enterprise Linux 7中得到完整的支持。這項工作計劃在OpenJDK 12中併入主線。

InfoQ:目前,OpenJDK垃圾回收方面的情況非常有意思。例如,截止JDK 11,G1最終成爲一個成熟的垃圾回收器。Red Hat有Shenandoah,而Oracle一直在開發ZGC。你能評論一下Red Hat在GC方面的參與情況嗎,特別是關於G1?你如何對比Shenandoah和ZGC?你能否估計一下Red Hat認爲Shenandoah會在什麼時候成爲一個生產就緒的垃圾回收器?

Sharples:目前,我們主要參與的仍然是Shenandoah GC。此外,在Hotspot的GC接口開發方面(儘管對用戶不可見)也進行了非常重要的協作,Red Hat正積極參與其中。

過去,GC代碼與Hotspot代碼交雜在一起,但現在每個GC的代碼都很好地分離出來了。Shenandoah與G1共享了一些代碼,所以需要做一些改進和bug修復。值得注意的是,G1採用了最初出現在Shenandoah中的一些特性,例如多線程Full GC,以及最近的空閒未提交堆(heap uncommit on idle)。

ZGC和Shenandoah的目標非常相似(減少收集大堆的停頓時間),但它們遵循的是非常不同的實現策略——Shenandoah使用Brooks Pointers,而ZGC使用彩色指針和多內存映射。

ZGC在吞吐量和停頓時間方面做得更好,而Shenandoah具有更好的人體工程學,這意味着它在一些惡劣的情況下(例如滿堆或堆分配激增)會運行得更好。ZGC不能(按照設計)使用壓縮的oops,這意味着它在中型(<32GB)的堆上有一定的弱勢。此外,Shenandoah在小堆上運行良好,這讓它有可能會成爲增長型應用程序的理想GC,但並不保證會這樣。

據我們所知,Shenandoah已經是JDK-8u發行版(Red Hat Enterprise Linux >= 7.5)的一部分。我們目前正在努力讓Shenandoah進入上游(JDK 12)。如果我們做到了,它將成爲一個實驗性特性。我們現在還不敢說這個實驗性標誌什麼時候將從上游OpenJDK發行版中移除。

InfoQ:顯然,最近的一個重大新聞是Red Hat被IBM收購。這將給Red Hat與OpenJDK之間的關係帶來什麼樣的影響?

Sharples:關於與收購有關的內容請參閱我們發佈的新聞和Jim Whitehurst的博文。

InfoQ:你認爲OpenJDK(以及Java/JVM生態系統)最激動人心的部分是什麼?你認爲哪些技術是我們的讀者在未來12到18個月內最應該關注的?

Sharples:Java必須超越當前的位置,也就是作爲大規模關鍵業務應用程序的可擴展語言運行時,並與更輕量、更靈活的語言和運行時展開競爭——特別是在內存佔用和延遲非常敏感的雲原生環境中。

Java社區繼續在JVM層面進行創新。除此之外,Graal和Substrate VM已經認識到,在容器和DevOps環境中,JVM的平均運行壽命要短得多。單體應用程序一次在JVM上可以運行數月,而持續交付環境中的容器化微服務可能一次只運行數天或數小時,而在無服務器環境中,它們可能只運行幾秒(甚至幾毫秒)。

值得注意的是,不僅僅是JVM令人感到興奮,更廣泛的Java生態系統也正極力追趕。除了優化JVM本身以及不斷引入像Thorntail這樣的新的輕量級和靈活的運行時之外,Eclipse MicroProfile及其規範也有助於將開發傳統單體應用程序的Java EE開發人員帶入輕量級微服務領域。

Red Hat,以及Fabic8 Maven Plugin和Spring Cloud Kubernetes等工具,一直在引領Kubernetes、Istio和OpenShift原生Java應用程序的開發。這極大簡化了微服務架構,而在幾年前,它們需要很多單獨管理的獨立基礎設施服務。整個Java生態系統在持續快速地向前發展。

我們也在考慮針對專門工作負載(如AI和機器學習)的芯片架構(如ARM和GPU)和雲架構的新元素,如邊緣設備、網關、移動設備和可穿戴設備。

InfoQ:還有其他想對我們讀者說的嗎?

Sharples:人們對Java興趣程度從未如此強烈,Java的未來也從未如此光明。

查看英文原文:

https://www.infoq.com/news/2018/11/red-hat-openjdk-gc-Nov18

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章