JavaScript 引擎 V8 发布 8.3 版本

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