V8 是 Google 发布的开源 JavaScript 引擎，采用 C++ 编写，在 Google 的 Chrome 浏览器中被使用。V8 引擎可以独立运行，也可以用来嵌入到 C++ 应用程序中执行。
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-8
