1. 原文

V8 release v6.8

2. 摘要翻译

Memory

JS函数不必要地保持外部函数以及他们的metadata存活（被作为 SharedFunctionInfo 或 SFI 而熟知）。特别在那些依赖短存活IIFE的重函数型代码，这个问题会导致比较严重的内存泄露。在这次改动之前，一个活跃的上下文：

通过将上下文指向一个 ScopeInfo 对象，包含了对 debugging 有用的简化信息，我们将 SFI 的依赖打破了。

我们在移动设备上前十名的页面上观测到了一个 3% 的 V8 内存提升。

此外，我们也降低了 SFI 自身的内存消耗，将不需要的字段删除或在必要的时候将其压缩，减少了 ~25% 左右的体积，将来的发布版本还会有进一步的减少。我们已经在传统网站上观测到了 SFI 占用了 2-6% 的 V8 内存，即便在将他们从上下文之中剥离出来之后，因此你可以期待在拥有大量函数的代码应用上观测到显著的内存提升。

Performance

Array destructuring improvements

正在优化的编译器并没有产生理想的数组解构代码。举例来说，使用[a, b] = [b, a]这样的代码进行变量交换会比const tmp = a; a = b; b = tmp慢两倍。当我们解锁 escape analysis 来评估所有的临时分配，使用临时数组的数组解构就和序列分配一样快了。

Object.assign improvements

迄今为止 Object.assign 有一个 C++ 编写的快速路径。这意味着每一次的 Object.assign 调用都必须穿越 JS-C++ 边界。很明显的为了提升内建的性能，最好就直接在JS端实现一个快速路径。我们有两个选项：将其实现为一个 native JS 内建函数（这会导致一些不必要的额外支出），或使用 CodeStubAssembler 技术来实现（这种方式提供了更多的弹性）。我们使用了第二种方案。新实现的 Object.assign 提升了大约 15% Speedometer2/React-Redux 的分数，也提升了 Speedometer 2 总体分数 1.5%。

TypedArray.prototype.sort improvements

TypedArray.prototype.sort 有两个路径：一个快速路径，使用在用户并没有提供一个比对函数的情况下，一个慢速路径用在其他的情况。直到现在，这个慢速路径都在重用 Array.prototype.sort 的实现，这个实现对排序 TypedArrays 来说有太多不必要的部分。V8 v6.8版本将慢速路径替换成了一个 CodeStubAssembler 实现。（并非直接使用 CodeStubAssembler制作，而是基于 CodeStubAssembler 制作的一个领域特定语言）

对 TypedArrays 的排序性能变化，当不提供比对函数的情况性能保持不变，而使用比对函数的情况则提速了 2.5倍。

WebAssembly

在 V8 v6.8版本你可以开始在 Linux x64 的平台上使用 trap-based bounds checking。内存管理的优化相当程度提升了 WebAssembly 的运行速度。它已经在 Chrome 68 中开始使用了，并在将来会逐步支持其他更多的平台。

V8 API

Please use git log branch-heads/6.7..branch-heads/6.8 include/v8.h to get a list of the API changes.

Developers with an active V8 checkout can use git checkout -b 6.8 -t branch-heads/6.8 to experiment with the new features in V8 v6.8. Alternatively you can subscribe to Chrome’s Beta channel and try the new features out yourself soon.

EOF