能否提供一個和 VM 獨立的 GC 庫？

01-13

垃圾收集應該是一種技巧性和專業性比較強的程序，VM 里 JIT 的部分也是技巧性和專業性比較強的，不過 JIT 和 GC 看上去好像是兩個比較獨立的部分，一方面的專家也可以不太懂另一方面。那麼人類能不能考慮提供一個開源的 GC 庫，VM 存對象和運行的時候按照一定約定，就可以用這個庫里的垃圾收集演算法，這個庫寫得比較好，而且能提供比較多的調整餘地，讓創造新語言的人可以「免費」獲得非常好的 GC 能力呢？
（是不是都提供 GC 了就不如直接提供一個運行時了 0.0

當然可以，而且已經有很多這方面的現成的庫了。

例如說，

給C或C++程序提供保守式 / 半保守式GC支持的 Boehm GC
源自Jikes RVM的 MMTk。這是個用Java實現的GC框架，內建豐富的GC演算法實現，也有許多GC研究是基於MMTk做的。除了Jikes RVM之外，它也有被若干其它runtime所利用，例如說VMKit——而VMKit的核心部分是用C++實現的，而它照樣可以用這個用Java實現的GC框架。
源自IBM J9的Eclipse OMR中的GC框架。這是用C++實現的GC框架，同樣內建豐富的GC演算法實現，是從IBM的產品級JVM——J9 VM——提取出來的。

這些都是成熟實用的選擇。

有些選項的「約定」比較簡單，例如說Boehm GC最低限度只要求用戶用它的GC_MALLOC()來分配要被GC管理的內存即可；而有的選項的「約定」就稍微複雜一些，要求用戶註冊棧上對被GC管理的對象的引用給GC庫，同時還要給GC描述對象的欄位布局來讓GC知道對象里什麼地方是GC要關心的指針。這是跟GC的工作模式相關的。相關背景信息可以參考個傳送門：找出棧上的指針/引用 - Script Ahead, Code Behind

題主的問題描述里有一點說得很對：

VM 里 JIT 的部分也是技巧性和專業性比較強的，不過 JIT 和 GC 看上去好像是兩個比較獨立的部分，一方面的專家也可以不太懂另一方面

確實對於高級編程語言的runtime來說，JIT和GC是跟runtime的其它部分相關性 / 偶合性都比較低的部分，比較容易做成相對獨立的組件。

像HotSpot VM這個JVM實現，其中的JIT編譯器和GC就是有相對明確的介面，比較容易製作新實現的；而這個JVM中runtime的其它部分的偶合性就比較強，沒那麼容易輕易剝離出來。

Eclipse OMR作為一個從產品JVM中剝離出來的組件套件，正好就跟題主所想像的各種場景都很吻合吧。

放幾個傳送門：

如何評價 IBM 的 Ruby + OMR？ - RednaxelaFX的回答
[新聞] IBM OMR項目正式開源 - 編程語言與高級語言虛擬機雜談（仮） - 知乎專欄
[新聞] IBM/Eclipse OMR的編譯器部分也已開源，以及IBM即將開源J9 VM - 編程語言與高級語言虛擬機雜談（仮） - 知乎專欄

@RednaxelaFX R大講的挺詳細了，不過感覺有些別的要說

如果是準確式GC+對象移動的話，就不太能是庫能解決的了，因為必須提供詳細的類型信息、內存布局，並且需要同時接管訪問指針操作，甚至在必要的時候stop the world。

總之就是一個功能如果在提供新操作，那麼一般比較好獨立成庫；然而如果有接管現有操作的需求，就不是那麼好做的了。