15 篇文章 含有標籤「WebAssembly」

JavaScript Promise Integration (JSPI) API 允許使用假設 同步 訪問外部功能編寫的 WebAssembly 應用程式在實際功能 非同步 的環境中順暢運行。

WebAssembly 的 JavaScript Promise Integration (JSPI) API 引入了全新的 API，適用於 Chrome M126 版本。我們將討論這些變更內容、如何配合 Emscripten 使用，以及 JSPI 的發展路線圖。

JSPI 是一個 API，允許使用同步 API 的 WebAssembly 應用程式訪問 非同步 的 Web API。許多 Web API 是基於 JavaScript Promise 對象設計的：它們不會立即執行請求的操作，而是返回一個 Promise 以執行操作。另一方面，許多編譯為 WebAssembly 的應用程式來自 C/C++ 界，這些程式通常使用會阻塞調用者直到完成的 API。

WebAssembly 的 JavaScript Promise Integration (JSPI) API 即將隨 Chrome M123 版本進入來源試驗。這意味著您可以測試您和您的用戶是否能從此新的 API 中受益。

JSPI 是一個 API，允許編譯成 WebAssembly 的所謂序列代碼訪問 非同步 的 Web API。許多 Web API 是以 JavaScript Promise 為基礎設計的：它們並未立即執行請求的操作，而是返回一個 Promise 來完成操作。當操作最終完成時，瀏覽器的任務執行器會使用 Promise 調用任何回調。JSPI 透過鉤入這種架構來允許 WebAssembly 應用程式在返回 Promise 時暫停，並在 Promise 被解析後恢復。

歡迎來到令人興奮的 V8 世界，在這裡速度不僅僅是一項功能，而是一種生活方式。當我們向 2023 年告別時，是時候慶祝 V8 今年取得的令人印象深刻的成就了。

通過創新的性能優化，V8 繼續在不斷演變的 Web 領域推進可能性的邊界。我們引入了一個新的中層編譯器，並對頂層編譯器基礎設施、運行時和垃圾回收器進行了多項改進，這些改進帶來了全方位的顯著速度提升。

最近的一篇關於 WebAssembly 垃圾回收 (WasmGC) 的文章從高層次解釋了 垃圾回收 (GC) 提案 如何更好地支持 Wasm 中的垃圾回收語言，這在考慮到它們的普及性時，非常重要。在本文中，我們將探討技術細節，了解像 Java、Kotlin、Dart、Python 和 C# 這樣的垃圾回收語言如何被移植到 Wasm。事實上有兩種主要的方法：

我們在 V8 v11.2 推出了 WebAssembly 尾呼叫！在本文中，我們將簡要概述此提案，展示 C++ 協程與 Emscripten 的一個有趣用例，並說明 V8 如何內部處理尾呼叫。

什麼是尾呼叫優化？​

一個呼叫被稱為處於尾部位置（tail position），如果它是目前函數在返回之前執行的最後指令。編譯器可以通過丟棄調用者的幀並將呼叫替換為跳轉來優化此類呼叫。

這對於遞歸函數特別有用。例如，以下是使用 C 寫成的函數計算鏈表中元素的總和：

int sum(List* list, int acc) {
  if (list == nullptr) return acc;
  return sum(list->next, acc + list->val);
}

使用常規呼叫，這將消耗 𝒪(n) 的堆棧空間：鏈表的每個元素都會在呼叫堆棧中增加一個新幀。鏈表足夠長時，可能很快就會導致堆棧溢出。通過將呼叫替換為跳轉，尾呼叫優化有效地將此遞歸函數轉換為使用 𝒪(1) 堆棧空間的循環：

V8 有兩個編譯器用於將 WebAssembly 程式碼編譯為可執行的機器代碼：基線編譯器 Liftoff 和優化編譯器 TurboFan。Liftoff 能比 TurboFan 更快地生成代碼，從而提供快速的啟動時間。而 TurboFan 則生成更快的代碼，從而實現高峰性能。

簡介​

由於 Chrome 和 Emscripten 的近期工作，您現在可以在 WebAssembly 應用程式中使用最多 4GB 的記憶體。這比之前的 2GB 限制有所提升。聽起來可能有些奇怪，記憶體的限制似乎本不應該存在——畢竟，使用 512MB 或 1GB 的記憶體並不需要特別的工作！——但事實證明，在從 2GB 跨越到 4GB 的過程中，無論是在瀏覽器還是工具鏈中，都發生了一些特別的變化，我們將在本篇文章中介紹。

我們有越來越多的編譯器和其他工具生成或操作 .wasm 文件，有時您可能想要看看其內部結構。也許您是此類工具的開發者，或者更直接地說，您是一個面向 Wasm 的程序員，並想了解生成的代碼模樣，這樣做是出於性能或其他原因。

Emscripten 一直以來主要專注於編譯到 Web 和其他像是 Node.js 的 JavaScript 環境。但隨著 WebAssembly 開始被 獨立於 JavaScript 使用，新的用例正在出現，因此我們一直在努力為 Emscripten 增加支援生成 獨立 Wasm 檔案的功能，這些檔案不依賴於 Emscripten 的 JS 運行時！這篇文章將解釋為什麼這很有趣。