上周Mozilla发布了火狐浏览器最新版本83.0。该版本中带来很多新功能和优化。其中最引人瞩目的当属，新高性能JS运行时Warp和安全加固的HTTPS模式。本文我们就一起来学习一下。

Warp

多层运行时JIT

运行JavaScript的第一步是将源代码解析为字节码（低级表示形式）。字节码可以使用解释器立即执行，也可以由即时（JIT）编译器编译为本地代码。现代的JavaScript引擎具有多层执行引擎。

JS功能可能会在层之间切换，具体取决于切换的预期收益：

解释器和基础运行时：该层具有快速的编译时间，仅执行基本代码优化，并收集性能分析数据。

优化JIT：执行编译器优化，但有慢编译时间和使用更多的内存。

优化的JIT根据其他层收集的概要分析数据进行假设。如果假设被证明是错误的，则将优化代码丢弃。发生这种情况时，该函数将在基线层中恢复执行，并且必须再次进行预热（bailout）。

整体上，可以用一个图来表示：

分析数据

老版本的优化运行时为Ion，它使用两个不同的系统来收集性能分析信息，指导JIT优化。第一个是类型推断（TI），它收集有关JS代码中使用的对象类型的全局信息。第二种是CacheIR，这是一种简单的线性字节码格式，被基础解释器和基础JIT用于基本优化原语。Ion主要依赖TI，但在TI数据不可用时会使用CacheIR信息。

在83版本中，使用Warp，更改了优化JIT，使其仅依赖于基线层收集的CacheIR数据。

值得注意的是，新版中已经使用更简单WarpBuilder（绿色标记）代替了IonBuilder（标记为红色）。IonBuilder和WarpBuilder都生成Ion MIR，这是优化JIT后端使用的中间表示。

在IonBuilder使用从整个引擎收集的TI数据生成MIR的情况下，WarpBuilder使用与基线解释器和Baseline JIT用于生成内联缓存（IC）的相同CacheIR来生成MIR。

CacheIR工作原理

考虑以下JS函数：

function f(o) {

return o.x - 1;

}

基础解释器和基础JIT使用两个同源缓存此功能：一个是属性访问（o.x），以及一个用于减法。这是因为不知道oand的类型就无法优化此功能o.x。

用于属性访问的ICo.x将以的值调用o。然后，它可以连接IC存根（一小段机器代码）以优化此操作。在SpiderMonkey中，这是通过首先生成CacheIR（一种简单的线性字节码格式，您可以将其视为优化方法）来工作的。例如，如果o是一个对象，并且x是一个简单的数据属性，将生成以下代码：

GuardToObject inputId 0

GuardShape objId 0，shapeOffset 0

LoadFixedSlotResult objId 0，offsetOffset 8

ReturnFromIC

在这里，首先保护输入（o）是一个对象，然后保护该对象的形状（确定对象的属性和布局），然后o.x从该对象的插槽中加载的值。

请注意，插槽数组中的形状和属性的索引存储在单独的数据节中，而不包含在CacheIR或IC代码本身中。CacheIR使用shapeOffset和引用这些字段的偏移量offsetOffset。这允许许多不同的IC存根共享相同的生成代码，从而减少了编译开销。

然后，IC将这个CacheIR代码片段编译为机器代码。现在，基线解释器和基线JIT可以快速执行此操作，而无需调用C++代码。

减法IC的工作方式相同。如果o.x为int32值，则将使用两个int32值调用减法IC，并且该IC将生成以下CacheIR来优化这种情况：

GuardToInt32 inputId 0

GuardToInt32 inputId 1

Int32SubResult lhsId 0, rhsId 1

ReturnFromIC

这样要保护左侧是一个int32值，然后要保护右侧是一个int32值，然后可以执行int32减法并将结果从IC Stub返回到函数。

CacheIR指令捕获了优化操作所需要做的一切。在YAML文件中定义了几百个CacheIR指令，这些是的JIT优化管道的基础。

将CacheIR转换为MIR

如果一个JS函数被多次调用，则希望使用优化编译器对其进行编译。使用Warp，需要执行三个步骤：

WarpOracle：在主线程上运行，创建一个包含Baseline CacheIR数据的快照。

WarpBuilder：在线程外运行，从快照构建MIR。

优化JIT后端：还运行线程外，优化MIR并生成机器代码。

WarpOracle阶段在主线程上运行，并且速度非常快。实际的MIR构建可以在后台线程上完成。这是对IonBuilder的改进，在IonBuilder上必须在主线程上进行MIR构建，因为它依赖于Type Inference的许多全局数据结构。

WarpBuilder有一个编译器，可将CacheIR转换为MIR。这是一个非常机械的过程：对于每个CacheIR指令，它只生成相应的MIR指令。

老的MIR构建器（IonBuilder）具有很多在WarpBuilder中不需要的复杂代码，因为所有JS语义都由IC所需的CacheIR数据捕获。

Trial Inlining

优化JavaScript JIT可以将JavaScript函数内联到调用方中。有了Warp， Warp还能够基于呼叫站点专门化内联函数。

对示例函数：

function f(o) {
return o.x - 1;
}

可以从多个地方调用此函数，每个地方传递不同形状的对象或的不同类型o.x。在这种情况下，即使每个调用方仅传递一种类型，内联高速缓存也将具有多态的CacheIR IC Stub。为了解决这个问题，新引入了一种称为Trial Inlining的新颖优化。每个功能都有一个ICScript，用于存储该功能的CacheIR和IC数据。在对函数进行Warp编译之前，先会扫描该函数中的Baseline IC，以搜索对可插入函数的调用。

Trial Inlining功能非常强大，因为可以递归工作。例如，考虑以下JS代码：

function callWithArg(fun, x) {
return fun(x);
}
function test(a) {
var b = callWithArg(x => x + 1, a);
var c = callWithArg(x => x - 1, a);
return b + c;
}

当该test函数执行试用内联时，将为每个callWithArg调用生成一个专用的ICScript。稍后尝试在那些调用方专用的callWithArg函数中Trial Inlining递归试验，然后可以fun基于调用方来专门化调用。这在IonBuilder中是不可能的。

是时候对该test函数进行Warp编译了，有了调用者专用的CacheIR数据，并且可以生成最佳代码。

通过递归地在调用站点上对Baseline IC数据进行专门处理，从而在对函数进行Warp编译之前就建立了内联图。然后，Warp只是基于此进行内联，而无需其自身的内联启发法。

优化内置功能

IonBuilder能够直接内联某些内置函数。这对于像特别有用Math.abs和Array.prototype.push，因可以用几个机器指令实现它们，这是一个很大的速度比调用该函数。

由于Warp由CacheIR驱动，决定为调用这些函数生成优化的CacheIR。

这意味着这些内置组件现在也已通过的基线解释器和JIT中的IC存根进行了适当的优化。新的设计使生成了正确的CacheIR指令，这不仅使Warp受益，而且使所有JIT层受益。

例如，看一下Math.pow带有两个int32参数的调用。生成以下CacheIR：

LoadArgumentFixedSlot resultId 1, slotIndex 3
GuardToObject inputId 1
GuardSpecificFunction funId 1, expectedOffset 0, nargsAndFlagsOffset 8
LoadArgumentFixedSlot resultId 2, slotIndex 1
LoadArgumentFixedSlot resultId 3, slotIndex 0
GuardToInt32 inputId 2
GuardToInt32 inputId 3
Int32PowResult lhsId 2, rhsId 3
ReturnFromIC

首先，要保护被调用者是内置pow函数。然后，加载两个参数并保护它们是int32值。然后，执行pow专门用于两个int32参数的操作，并从IC Stub返回结果。

此外，Int32PowResultCacheIR指令还用于优化JS幂运算符，x ** y。对于该运算符，会生成：

GuardToInt32 inputId 0
GuardToInt32 inputId 1
Int32PowResult lhsId 0, rhsId 1
ReturnFromIC

当添加了对的Warp Transpiler支持时Int32PowResult，Warp可以优化指数运算符，Math.pow而无需进行其他更改。这是CacheIR提供了可用于优化不同操作的构建块的一个很好的示例。

Warp引擎下JS性能改善

在许多工作负载下，Warp比Ion要快很多。官方测试中：Google Docs的加载时间缩短了20%，而Speedometer基准测试速度提高了约10-12%：

Reddit和Netflix等其他JS密集型站点上也看到了类似的页面加载和响应速度改进。

这些改进很大程度上是因为基于CacheIR的Warp使可以删除整个引擎中的代码，这些代码是跟踪IonBuilder使用的全局类型推断数据所需的，从而提高了整个引擎的速度。

旧引擎需要所有功能来跟踪类型信息，这些信息仅在非常热门的功能中有用。使用Warp时，用于优化Warp的性能分析信息（CacheIR）也用于加速在Baseline Interpreter和Baseline JIT中运行的代码。

Warp还能够在线程外执行更多工作，并且所需的重新编译次数更少（以前的设计通常过于专业化，从而导致许多救援）。

内存使用

删除全局类型推断数据也意味着使用更少的内存。例如，下图显示了在加载多个网站（tp6）时Firefox中的JS代码使用的内存减少8%：

更快的GC

类型推断数据也为垃圾回收增加了很多开销。9月23日在Firefox Nightly中默认启用Warp时，于GC扫描的测试数据有了一些重大改进（GC的阶段之一）：

可维护性和开发人员速度

WarpBuilder比IonBuilder代码更简单，更紧凑，更可维护且更不易出错。通过在各处使用CacheIR，可以使用更少的代码来添加新的优化。这使团队更容易提高性能并实现新功能。

HTTPS-Only模式

网络安全至关重要。网页中输入密码，信用卡号或其他敏感信息时，都希望确保此信息的安全性。无论个人电子邮件还是阅读病历页面，都应该将这些信息泄露给窃听者。

Mozilla在Firefox 83中新推出了很高兴推出HTTPS-Only模式，启用HTTPS-Only 模式时：

Firefox尝试与每个网站建立完全安全的连接，并且

在连接到不支持安全连接的网站之前，Firefox会需要征求用户确认。

HTTPS-Only介绍

超文本传输​协议（HTTP）是Web浏览器和网站通过其进行通信的基本协议。但是，通过常规HTTP协议传输的数据不受保护，并以明文形式传输，因此攻击者可以查看，窃取甚至篡改所传输的数据。（HTTPS）通过在浏览器和用户访问的网站之间建立安全和加密的连接来解决该问题。当在地址栏中看到锁定图标时，表明网站正在使用HTTPS：

大多数网站已经支持HTTPS，而那些不常见的网站支持HTTPS的也越来越多，一个常见的问题是网站会混用http和https模式，或者只有部分内容用https，这些不安全版本

目前HTTPS的可用性很高， Firefox增加了HTTPS-Only 模式，未经用户许可，浏览器不再创建任何不安全的访问。

无论单击HTTP链接还是手动输入HTTP地址，Firefox都将使用HTTPS。升级结果如下：

设置HTTPS-Only模式和临时放通

HTTPS-Only模式开启很简单：

单击Firefox的菜单按钮，点击"选项"。

选择"隐私与安全性"，然后向下滚动到"HTTPS-Only模式"部分。

选择"在所有窗口中启用HTTPS-Only模式"。

启用"仅HTTPS模式"后，可以像往常一样浏览网络，并确信Firefox将在可能的情况下将网络连接升级为安全状态，并默认保持安全。对于少数尚不支持HTTPS的网站，Firefox将显示一条错误消息，解释安全风险并询问是否要使用HTTP连接到该网站。错误消息如下所示：

如果网站部分内容不支持HTTPS访问情况下，在该模式下某些网页可能看起来不正确或可能出现故障。在这种情况下，可以通过单击地址栏中的锁定图标来暂时禁用该站点的仅HTTPS模式：

总结

本文我们介绍了火狐83浏览器带来的性能上和安全上的改善。Warp对JS的执行性能有了大幅度的提高，而HTTPS-Only模式则大大提高了整个网络的安全性。建议大家都尽快升级尝试新的功能和改善。