擁抱WebAssembly的日子終于到來！

作者：朱先忠 2023-03-27 13:25:18

本文將回顧為什么1.0版本的WebAssembly不是Scheme的好目標(biāo)，變通方法是什么，新設(shè)施是什么，實(shí)現(xiàn)將如何利用它們，以及仍然存在哪些限制。在2-3年內(nèi)，WebAssembly將成為我們許多最熟悉的語言的優(yōu)秀編譯目標(biāo)和語言運(yùn)行時(shí)基礎(chǔ)。

譯者 | 朱先忠

策劃 | 云昭

WebAssembly已經(jīng)存在了一段時(shí)間，但到目前為止，它對高級(jí)語言的實(shí)用性有限，尤其是使用垃圾收集的語言。然而，隨著web瀏覽器即將推出對托管內(nèi)存的支持，情況即將發(fā)生變化，這使得WebAssembly成為Scheme、OCaml以及所有非C++或Rust使用者的可行目標(biāo)。

WebAssembly，終于要來了。

1、現(xiàn)實(shí)中的WebAssembly

WebAssembly可以看作是C編譯器的一個(gè)奇怪的后端。目前，只有少數(shù)幾種源語言能夠成功運(yùn)行在WebAssembly上。

Haskell、Ocaml、Scheme、F#等語言呢？我們呢？我們只算是一些懶蟲嗎？

那我們?yōu)槭裁床辉谀抢锬兀縒ebAssembly上的Clojure在哪里？F#、Elixir和Haskell編譯器在哪里？人們早期的確作出一些努力，但并沒有真正成功。為什么？我們只是沒有付出努力嗎？為什么Rust語言可以飛速發(fā)展，而Scheme語言卻沒有呢？

WebAssembly的1.0和2.0版本還不能算是良好的支持垃圾收集的語言，讓我們仔細(xì)看看其原因。

事實(shí)證明，在WebAssembly上尚不存在好的Scheme語言實(shí)現(xiàn)是有原因的：如果您的語言依賴于存在垃圾收集器的話，那么WebAssembly的初始版本就是一個(gè)可怕的目標(biāo)。盡管已經(jīng)取得了一些進(jìn)展，但對于當(dāng)前標(biāo)準(zhǔn)化和部署的WebAssembly版本仍然有待觀察。為了更好地理解這個(gè)問題，讓我們深入研究這個(gè)系統(tǒng)的內(nèi)部，看看它的局限性是什么。

2、GC和WebAssembly 1.0

基于垃圾收集（GC：Gabage Collecting）的值類型存儲(chǔ)在什么地方呢？

對于WebAssembly 1.0而言，唯一可能的答案是：線性內(nèi)存。

(module
(global $hp (mut i32) (i32.const 0))
(memory $mem 10)) ;; 640 kB

WebAssembly 1.0為您提供的表示數(shù)據(jù)的原型是所謂的線性內(nèi)存：其實(shí)，也就是一個(gè)可以讀取和寫入的字節(jié)緩沖區(qū)。除了內(nèi)存布局更簡單之外，這與本機(jī)編譯時(shí)得到的非常相似。您可以以64 KB的頁面為單位獲取此內(nèi)存。在上面的例子中，我們將請求10個(gè)頁面，640kB。應(yīng)該足夠了，對吧？我們將把它全部用于垃圾收集器，并使用一個(gè)凹凸指針分配器。堆指針/分配指針保存在可變?nèi)肿兞?hp中。

(func $alloc (param $size i32) (result i32)
(local $ret i32)
(loop $retry
(local.set $ret (global.get $hp))
(global.set $hp
(i32.add (local.get $size) (local.get $ret)))

(br_if 1
(i32.lt_u (i32.shr_u (global.get $hp) 16)
(memory.size))
(local.get $ret))

(call $gc)
(br $retry)))

這里給出了分配函數(shù)的樣子。分配函數(shù)$alloc類似于C語言中的malloc函數(shù)：它使用一些字節(jié)作參數(shù)并返回一個(gè)指針。在WebAssembly中，指向內(nèi)存的指針只是一個(gè)偏移量，它是一個(gè)32位整數(shù)（i32）。（使用64位地址空間的選項(xiàng)已經(jīng)納入計(jì)劃中，但還不是標(biāo)準(zhǔn)的實(shí)現(xiàn)。）

如果這是您第一次看到WebAssembly函數(shù)的文本表示，那么您可以盡情地學(xué)習(xí)一下，但這卻不是我上面演示內(nèi)容的重點(diǎn)；我想強(qiáng)調(diào)的是call $gc——當(dāng)分配指針到達(dá)區(qū)域的末尾時(shí)所發(fā)生的事情。

3、GC和WebAssembly 1.0（1）

調(diào)用$gc背后隱藏著什么？答案是：通過線性內(nèi)存運(yùn)送GC。基于“Stop-The-World”技術(shù)，采取非并行、非并發(fā)機(jī)制，而是……根節(jié)點(diǎn)。

首先要注意的是，您必須自己提供$gc。當(dāng)然，這是可行的——這就是我們在編譯到本地目標(biāo)時(shí)所要做的工作。

不幸的是，盡管WebAssembly中的多線程支持有些不足；不過，它允許您共享內(nèi)存并使用原子操作，只是您必須在WebAssembly之外創(chuàng)建線程。在開發(fā)實(shí)踐中，您交付的GC可能沒有利用多線程優(yōu)勢，因此它可能是相當(dāng)原生態(tài)的，以致于將所有垃圾收集工作推遲到“Stop-The-World”階段。

4、GC和WebAssembly 1.0（2）

活動(dòng)對象包括：

根（roots）節(jié)點(diǎn)
活動(dòng)對象引用的任何對象

其中，根（roots）節(jié)點(diǎn)是活動(dòng)堆棧幀中的全局值與局部值。

注意：你無法通過編程來訪問活動(dòng)堆棧幀。

更糟糕的是，您無法訪問堆棧上的根（roots）節(jié)點(diǎn)。一個(gè)GC必須保留活動(dòng)對象——它們是被循環(huán)定義為根引用的任何對象或活動(dòng)對象引用的任何物體。從根節(jié)點(diǎn)開始，作為全局變量或者是被活動(dòng)堆棧框架引用的任何GC托管對象。

但是，這種情況下我們遇到了問題，因?yàn)樵赪ebAssembly（任何版本，而不僅僅是1.0版本）中，你不能遍歷堆棧，所以你根本找不到活動(dòng)的堆棧幀；當(dāng)然，這樣一來你也找不到堆棧根節(jié)點(diǎn)。（有時(shí)，人們希望將其作為一種低級(jí)別的能力來支持；但一般來說，最后形成的共識(shí)似乎是，如果由引擎來負(fù)責(zé)實(shí)現(xiàn)GC機(jī)制，那么系統(tǒng)的整體性能會(huì)更好一些；但目前這僅是一個(gè)預(yù)兆而已！）

5、GC和WebAssembly 1.0（3）

針對上述問題，一種變通的解決方案是：

精確控制堆棧的根節(jié)點(diǎn)
將所有可能的指針值溢出到線性內(nèi)存并保守地收集

考慮到堆棧的不可迭代性，基本上有兩種變通的解決方案。一種是讓編譯器和運(yùn)行時(shí)維護(hù)對象根節(jié)點(diǎn)的顯式堆棧；這樣一來，垃圾收集器可以確定這些根節(jié)點(diǎn)是指針。這種辦法很好，因?yàn)樗梢宰屇阋苿?dòng)物體。但是，維護(hù)堆棧也是一筆開銷；基于現(xiàn)有技術(shù)的解決方案是創(chuàng)建一個(gè)輔助表（“堆棧映射”），將可以調(diào)用GC的每個(gè)潛在點(diǎn)與如何找到根節(jié)點(diǎn)的指令相關(guān)聯(lián)。

另一種解決方法是將整個(gè)堆棧溢出到內(nèi)存中。或者，可能只是類似指針的值；無論如何，需要保守地掃描所有關(guān)鍵詞，以便搜索到可能是根節(jié)點(diǎn)的東西。但是，采用這種方案的話需要我們必須自己訪問內(nèi)存，而不是訪問WebAssembly實(shí)現(xiàn)會(huì)溢出堆棧到達(dá)的內(nèi)存區(qū)。這種方案可能還湊合；但它算是次優(yōu)的。有興趣的讀者可以參閱我最近關(guān)于Whippet垃圾收集器的帖子（https://wingolog.org/archives/2023/02/07/whippet-towards-a-new-local-maximum），以深入了解基于保守性根節(jié)點(diǎn)搜索的含義。

6、GC和WebAssembly 1.0（4）

· 無法收集外部對象（如JavaScript）的循環(huán)。

· 指向GC托管對象的指針是對線性內(nèi)存的偏移，需要在線性內(nèi)存上具有從外部·讀取/寫入對象的能力。

· 無法將內(nèi)存回饋給操作系統(tǒng)。

· 想進(jìn)行詳細(xì)的“腸道檢查”：它的回答是“NO”。

如果僅此而已，情況就不那么好了，而且情況會(huì)變得更糟！線性內(nèi)存GC的另一個(gè)問題是，它限制了將多個(gè)模塊和主機(jī)組合在一起的可能性，因?yàn)樵赪eb瀏覽器中管理JavaScript對象的垃圾收集器對線性內(nèi)存上的垃圾收集器一無所知。在這樣的系統(tǒng)中，您可以很容易地創(chuàng)建內(nèi)存泄漏。

此外，為了讀取或?qū)懭雽ο蟮淖侄危瑢€性內(nèi)存中對象的引用需要對所有線性內(nèi)存進(jìn)行任意讀寫訪問，這一點(diǎn)非常令人討厭。那么，如何在適當(dāng)修改的情況下構(gòu)建一個(gè)可靠的系統(tǒng)呢？

最后，一旦你收集了垃圾，也許你設(shè)法壓縮了內(nèi)存，你就不能返回給操作系統(tǒng)任何東西了。對于這點(diǎn)，已經(jīng)有一些建議正在醞釀中，但還沒有實(shí)現(xiàn)。

如果BOB的觀眾必須在“更糟糕的是更好的”和“正確的事情”之間做出選擇的話，我認(rèn)為BOB的觀眾更接近于選擇“正確的事情”。像這樣的觀眾本能地會(huì)對丑陋的系統(tǒng)感到厭惡；我認(rèn)為GC相對于線性存儲(chǔ)差不多也描述了一個(gè)丑陋的系統(tǒng)。

7、GC和WebAssembly 1.0（5）

瀏覽器中已經(jīng)存在一個(gè)高性能并發(fā)并行壓縮的GC了。

Halftime: C++ N – Altlangs 0

關(guān)鍵是，WebAssembly 1.0要求您編寫和交付一個(gè)糟糕的GC，而主機(jī)中可能已經(jīng)有一個(gè)很棒的GC——一個(gè)投入了數(shù)百人年努力的GC，一個(gè)肯定會(huì)做得比你做得更好的GC。web瀏覽器中托管的WebAssembly應(yīng)該可以訪問瀏覽器的垃圾收集器！

我有一種感覺，當(dāng)我們這些對垃圾收集語言情有獨(dú)鐘的人，一直站旁觀席上時(shí)，Rust和C++程序員們卻一直忙于“在球場上進(jìn)球”。是的，他們被“球”絆倒了，但最終他們還是設(shè)法在擊“球”距離內(nèi)成功了。

8、變革即將到來！

對內(nèi)置GC的支持將于2023年第四季度推出。

有了GC，基本條件已經(jīng)到位。

讓我們將語言編譯到WebAssembly。

為了繼續(xù)使用體育環(huán)境下“足球”的比喻，我認(rèn)為在下半場，我們的球員將最終能夠上場，并達(dá)到眾所周知的110%。WebAssembly用戶開始支持垃圾收集，我認(rèn)為即使到今年年底，它也將在主要瀏覽器中推出。這將是一個(gè)大事件！我們有機(jī)會(huì)，我們需要好好把握。

當(dāng)然，正如我前面所提到的，WebAssembly仍然是一臺(tái)奇怪的機(jī)器：作為編譯目標(biāo)有些奇怪，在運(yùn)行時(shí)也是如此。對于調(diào)試支持方面，簡直是一場恰到好處的混亂；也許過段時(shí)間會(huì)有其他關(guān)于這方面的文章。

對于如何表示字符串，這是一個(gè)令人驚訝的棘手問題；在WebAssembly標(biāo)準(zhǔn)社區(qū)中，有人認(rèn)為JavaScript和WebAssembly可以共享底層字符串表示，也有人認(rèn)為這是一件愚蠢的事，而認(rèn)為復(fù)制是唯一的出路。我不知道哪一方會(huì)獲勝；也許稍后也會(huì)有更多關(guān)于這方面的內(nèi)容。

類似地，與JavaScript的整個(gè)互操作問題在很大程度上處于早期階段，目前的情況是選擇什么都不做而不是做錯(cuò)事。您可以將WebAssembly（ref-eq）傳遞給JavaScript，但JavaScript對它無能為力：它沒有原型。現(xiàn)有技術(shù)還提供了一個(gè)JS運(yùn)行時(shí)，它封裝了每個(gè)wasm對象，將wasm模塊中導(dǎo)出的函數(shù)代理為對象方法。

最后，一些語言實(shí)現(xiàn)確實(shí)需要JIT支持，比如PyPy。

9、總結(jié)

有了GC支持，WebAssembly現(xiàn)在已經(jīng)為我們準(zhǔn)備好了。

把我們熟悉的語言放在WebAssembly上現(xiàn)在已經(jīng)是一件很容易的事情了。

那么，讓我們在下半場進(jìn)球吧！

請?jiān)L問以下有關(guān)鏈接：

"gitlab.com/spritely/guile-hoot-updates"
"wingolog.org"
"wingo@igalia.com"
"igalia.com"
"mastodon.social/@wingo"

事實(shí)證明，WebAssembly在C、C++、Rust等方面取得了一些巨大的勝利，但現(xiàn)在輪到我們參與到游戲中了。GC即將到來，作為一個(gè)社區(qū)，我們需要準(zhǔn)備好編譯器和語言運(yùn)行時(shí)。讓我們沖好咖啡，把一些字節(jié)放在一起；現(xiàn)在還為時(shí)過早，不過，對于擁有最佳WebAssembly體驗(yàn)的語言社區(qū)來說，這是一個(gè)值得贏得的世界。

10、WebAssembly是一個(gè)令人興奮的新型通用計(jì)算平臺(tái)

WebAssembly到底是什么？它不是一種你用于編寫軟件的編程語言，而是一種編譯目標(biāo)：如果你愿意學(xué)習(xí)的話，它基本算是一種匯編語言。

對于此平臺(tái)，它擁有可預(yù)測的便攜性能：

低層級(jí)上運(yùn)行
本地代碼約占不到10%

通過隔離實(shí)現(xiàn)可靠的組合：

默認(rèn)情況下，模塊不共享任何內(nèi)容
沒有夢魘般錯(cuò)誤
提供內(nèi)存沙盒支持

你需要將代碼編譯到WebAssembly，以便更輕松地進(jìn)行部署和創(chuàng)作。

如果你把WebAssembly的特點(diǎn)看作一臺(tái)抽象機(jī)器；那么，對我來說，它在以下兩個(gè)主要領(lǐng)域比其他機(jī)器有所進(jìn)步。

首先，它接近本質(zhì)——例如，如果您將圖像處理庫編譯到WebAssembly并運(yùn)行它，與將其編譯到x86-64或ARMv8或其他版本相比，您將獲得類似的性能。（特別是對于圖像處理，本地運(yùn)行通常仍然會(huì)獲勝，因?yàn)閃ebAssembly中的SIMD（單指令多數(shù)據(jù)流）原語更窄，而且將圖像放入和取出WebAssembly可能意味著一個(gè)要?jiǎng)?chuàng)建一個(gè)副本。）WebAssembly的指令集涵蓋了廣泛的低級(jí)別操作，這使編譯器能夠生成高效的代碼。

這里的新穎之處在于WebAssembly既可移植，又很成功。我們這些程序員“怪人”知道，僅僅在技術(shù)上做得更好是不夠的：你還必須成功地為你的替代方案爭取吸引力。

第二個(gè)有趣的特征是，WebAssembly（一般來說）遵循最小權(quán)限體系架構(gòu)：WebAssembly模塊從一開始就只能夠訪問它自己。模塊實(shí)例所具有的任何功能都必須在實(shí)例化時(shí)由主機(jī)顯式地與其共享。這不同于可以訪問所有主內(nèi)存的DLL，也不同于可以改變?nèi)謱ο蟮腏avaScript庫。這一特性使WebAssembly模塊能夠可靠地組成更大的系統(tǒng)。