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 在原型链上时不使用快速查找处理程序来解决此问题。这种情况并不常见，在基准测试中尚未发现任何性能下降的情况。

注意：本文归作者所有，未经作者允许，不得转载