内容简介：JavaScript 引擎 V8 发布了 8.3 版本（测试阶段），正式版本将在之后随 Chrome 83 一起推出。8.3 版本带来了一些面向开发人员的特性，主要亮点包括： 性能 垃圾收集器中更快的 ArrayBuffer 跟踪 ArrayBuffer 的后...
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
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
