JavaScript 引擎 V8 發布了 8.3 版本（測試階段），正式版本將在之後隨 Chrome 83 一起推出。8.3 版本帶來了一些面向開發人員的特性，主要亮點包括：
垃圾收集器中更快的 ArrayBuffer 跟蹤
ArrayBuffer 的後備存儲是使用嵌入器提供的 ArrayBuffer::Allocator 在 V8 堆之外分配的。當垃圾收集器回收其 ArrayBuffer 對象時，需要釋放這些後備存儲。V8 v8.3 具有跟蹤 ArrayBuffer 及其後備存儲的新機制，該機制允許垃圾回收器迭代並同時將後備存儲釋放給應用程序。這將 ArrayBuffer 繁重的工作負載中的總 GC 暫停時間減少了 50％。
更大的 Wasm 記憶體
根據 WebAssembly 規范的更新，V8 v8.3 現在允許模塊請求最大為 4GB 的記憶體，從而允許將更多記憶體密集型用例引入 V8 驅動的平台。要注意的是，這麼多的記憶體可能並不總是在用戶的系統上可用；建議以較小的大小創建記憶體，根據需要進行擴展，並適當地處理增長失敗的情況。
修復
存儲到原型鏈上具有類型數組的對象
根據 JavaScript 規范，當將值存儲到指定鍵時，需要查找原型鏈，以查看鍵是否已存在於原型中。這些密鑰通常不存在於原型鏈中，因此 V8 安裝了快速查找處理程序。
但最近在某些特殊情況中，V8 錯誤地安裝了此快速查找處理程序，從而導致了錯誤的行為。當 TypedArray 在原型鏈上時，所有存儲到 TypedArray 的 OOB 的鍵都應被忽略。例如，在低於 v[2] 的情況下，不應向 v 添加屬性，並且後續讀取應返回 undefined。
v = {};v.__proto__ = new Int32Array(1);v[2] = 123;return v[2]; // Should return undefined
V8 的快速查找處理程序無法處理這種情況，因此在上例中，將返回 123 。V8 v8.3 通過在 TypedArrays 在原型鏈上時不使用快速查找處理程序來解決此問題。這種情況並不常見，在基準測試中尚未發現任何性能下降的情況。
更新說明：
https://v8.dev/blog/v8-release-83
來源：cnBeta
