IBM創建了Eclipse OMR,一個用于為任何語言創建運行時環境的開源虛擬機工具包。OMR旨在讓各種語言都能利用虛擬機技術的一般改進,像垃圾收集或硬件集成。為此,IBM正在推廣自己名為J9的JVM。
雖然JVM日益成為許多語言的通用運行時,但它同Java語言的緊密關系意味著其設計和功能的很大一部分都是同Java本身緊密相關的。這就使得在嘗試使用JVM作為其他語言的運行時時會遇到挑戰,尤其是動態類型的語言: 在Java 7引入InvokeDynamic之前,動態語言都不得不使用低效的變通方案來克服JVM的靜態類型特性,嚴重影響了性能。就像Daryl Maier和其他OMR項目成員所說的那樣,這給語言創建者兩種選擇:要么從頭開始為新語言創建一個運行時,這會帶來難以承受的成本,或者,就像大多數團隊所做的那樣,調整語言,讓它可以使用已有的運行時環境,接受它的限制。
OMR提供了第三種選擇。雖然OMR本身不是一個運行時,但它是一個讓你可以輕松創建運行時的工具包。OMR是通過重構IBM Java虛擬機J9的組件創建出來的,對于任何運行時中最常見的功能,它都提供了一種語言無關的實現,同時,它還提供了一套接口,用于創建接口作者所說的“語言膠水(language glue)”或者是特定于語言的代碼,作為OMR提供的通用功能同需要處理的語言細節之間的橋梁。將OMR同語言膠水相結合,語言設計者就可以獲得一個包含如下功能的運行時:
內存分配器 線程庫 用于將運行時移植到不同平臺的硬件抽象層 用于連接不同運行時和操作系統事件的事件鉤子框架 用于調式及其他目的的跟蹤引擎 垃圾收集 JIT編譯器為了促進推廣,語言膠水接口并不需要從頭全部實現,語言設計者可以根據他們想要獲得的運行時功能僅實現其中的一部分。例如,簡單地實現這些API中的三個就可以獲得一個單線程的標記/清除垃圾收集功能,而實現更多的接口就可以獲得并發標記、并行或分代收集功能。
這次重構有一個有趣的副作用,就是單個組件更容易測試了。在這次修改之前,像垃圾收集這樣的組件只能使用整個運行時來執行,這意味著測試需要大量復雜的設置和分析。不過,在對這個復雜的邏輯進行分隔和解耦之后,單個組件可以隔離測試了,這簡化了測試設置和分析。
不過,OMR最有前途的特性可能是它將成為一個由Eclipse基金會(IBM是其戰略成員)運作的開源項目。項目負責人希望Eclipse基金會培養一個開發者社區,為OMR提供創新性貢獻,所有以OMR工具包為基礎創建運行時的語言都可以從中受益。這有助于OMR攻占OpenJDK的領地,后者雖然也是開源的,但它在吸收有價值的貢獻時一直有些困難,比如谷歌對CMS所做的性能改進。
然而,這種方法也有缺點。雖然迫使語言設計者采用一種已有的運行時可能會帶來一些挑戰,但那也意味著不同的語言可以同時在同一個虛擬機中運行,這樣就便于語言互操作。OMR為每種語言創建一個不同的運行時的方法意味著,即使可能,實現互操作也要困難許多。最終的結果可能是,不同的語言設計者根據自己的戰略重點,在易于互操作和易于語言開發之間作出權衡,選擇這一個或其他方法。
查看英文原文:IBM Kick-Starts Eclipse OMR, a Toolkit for Creating Language Runtimes