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。
<code>v = {};
v.__proto__ = new
Int32Array(1
);
v[2
] = 123
;
return
v[2
]; //
Should return
undefined
/<code>V8 的快速查找處理程序無法處理這種情況，因此在上例中，將返回 123 。V8 v8.3 通過在 TypedArrays 在原型鏈上時不使用快速查找處理程序來解決此問題。這種情況並不常見，在基準測試中尚未發現任何性能下降的情況。
