分类软件开发下的文章

开发一个 Linux 调试器（八）：堆栈展开

Simon Brand 发布于 2017-10-05
另请参阅: 软件开发,调试
评论

有时你需要知道的最重要的信息是什么，你当前的程序状态是如何到达那里的。有一个 backtrace 命令，它给你提供了程序当前的函数调用链。这篇文章将向你展示如何在 x86\_64 上实现堆栈展开以生成这样的回溯。

系列索引

这些链接将会随着其他帖子的发布而上线。

用下面的程序作为例子：

void a() {
    //stopped here
}

void b() {
     a();
}

void c() {
     a();
}

int main() {
    b();
    c();
}

如果调试器停在 //stopped here' 这行，那么有两种方法可以达到：main->b->a或main->c->a`。如果我们用 LLDB 设置一个断点，继续执行并请求一个回溯，那么我们将得到以下内容：

* frame #0: 0x00000000004004da a.out`a() + 4 at bt.cpp:3
  frame #1: 0x00000000004004e6 a.out`b() + 9 at bt.cpp:6
  frame #2: 0x00000000004004fe a.out`main + 9 at bt.cpp:14
  frame #3: 0x00007ffff7a2e830 libc.so.6`__libc_start_main + 240 at libc-start.c:291
  frame #4: 0x0000000000400409 a.out`_start + 41

这说明我们目前在函数 a 中，a 从函数 b 中跳转，b 从 main 中跳转等等。最后两个帧是编译器如何引导 main 函数的。

现在的问题是我们如何在 x86\_64 上实现。最稳健的方法是解析 ELF 文件的 .eh_frame 部分，并解决如何从那里展开堆栈，但这会很痛苦。你可以使用 libunwind 或类似的来做，但这很无聊。相反，我们假设编译器以某种方式设置了堆栈，我们将手动遍历它。为了做到这一点，我们首先需要了解堆栈的布局。

            High
        |   ...   |
        +---------+
     +24|  Arg 1  |
        +---------+
     +16|  Arg 2  |
        +---------+
     + 8| Return  |
        +---------+
EBP+--> |Saved EBP|
        +---------+
     - 8|  Var 1  |
        +---------+
ESP+--> |  Var 2  |
        +---------+
        |   ...   |
            Low

如你所见，最后一个堆栈帧的帧指针存储在当前堆栈帧的开始处，创建一个链接的指针列表。堆栈依据这个链表解开。我们可以通过查找 DWARF 信息中的返回地址来找出列表中下一帧的函数。一些编译器将忽略跟踪 EBP 的帧基址，因为这可以表示为 ESP 的偏移量，并可以释放一个额外的寄存器。即使启用了优化，传递 -fno-omit-frame-pointer 到 GCC 或 Clang 会强制它遵循我们依赖的约定。

我们将在 print_backtrace 函数中完成所有的工作：

void debugger::print_backtrace() {

首先要决定的是使用什么格式打印出帧信息。我用了一个 lambda 来推出这个方法：

    auto output_frame = [frame_number = 0] (auto&& func) mutable {
        std::cout << "frame #" << frame_number++ << ": 0x" << dwarf::at_low_pc(func)
                  << ' ' << dwarf::at_name(func) << std::endl;
    };

打印输出的第一帧是当前正在执行的帧。我们可以通过查找 DWARF 中的当前程序计数器来获取此帧的信息：

    auto current_func = get_function_from_pc(get_pc());
    output_frame(current_func);

接下来我们需要获取当前函数的帧指针和返回地址。帧指针存储在 rbp 寄存器中，返回地址是从帧指针堆栈起的 8 字节。

    auto frame_pointer = get_register_value(m_pid, reg::rbp);
    auto return_address = read_memory(frame_pointer+8);

现在我们拥有了展开堆栈所需的所有信息。我只需要继续展开，直到调试器命中 main，但是当帧指针为 0x0 时，你也可以选择停止，这些是你在调用 main 函数之前调用的函数。我们将从每帧抓取帧指针和返回地址，并打印出信息。

    while (dwarf::at_name(current_func) != "main") {
        current_func = get_function_from_pc(return_address);
        output_frame(current_func);
        frame_pointer = read_memory(frame_pointer);
        return_address = read_memory(frame_pointer+8);
    }
}

就是这样！以下是整个函数：

void debugger::print_backtrace() {
    auto output_frame = [frame_number = 0] (auto&& func) mutable {
        std::cout << "frame #" << frame_number++ << ": 0x" << dwarf::at_low_pc(func)
                  << ' ' << dwarf::at_name(func) << std::endl;
    };

    auto current_func = get_function_from_pc(get_pc());
    output_frame(current_func);

    auto frame_pointer = get_register_value(m_pid, reg::rbp);
    auto return_address = read_memory(frame_pointer+8);

    while (dwarf::at_name(current_func) != "main") {
        current_func = get_function_from_pc(return_address);
        output_frame(current_func);
        frame_pointer = read_memory(frame_pointer);
        return_address = read_memory(frame_pointer+8);
    }
}

添加命令

当然，我们必须向用户公开这个命令。

    else if(is_prefix(command, "backtrace")) {
        print_backtrace();
    }

测试

测试此功能的一个方法是通过编写一个测试程序与一堆互相调用的小函数。设置几个断点，跳到代码附近，并确保你的回溯是准确的。

我们已经从一个只能产生并附加到其他程序的程序走了很长的路。本系列的倒数第二篇文章将通过支持读写变量来完成调试器的实现。在此之前，你可以在这里找到这个帖子的代码。

via: https://blog.tartanllama.xyz/c++/2017/06/24/writing-a-linux-debugger-unwinding/

作者：Simon Brand 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

从 Node 到 Go：一个粗略的比较

John Stamatakos 发布于 2017-10-01
另请参阅: 软件开发,Node.js, golang
1 条评论

在 XO 公司，我们最初使用 Node 和 Ruby 构建相互连接的服务系统。我们享受 Node 带来的明显性能优势，以及可以访问已有的大型软件包仓库。我们也可以轻松地在公司内部发布并复用已有的插件和模块。极大地提高了开发效率，使得我们可以快速编写出可拓展的和可靠的应用。而且，庞大的 Node 社区使我们的工程师向开源软件贡献更加容易（比如 BunnyBus 和 Felicity）。

虽然我在大学时期和刚刚工作的一些时间在使用更严谨的编译语言，比如 C++ 和 C#，而后来我开始使用 JavaScript。我很喜欢它的自由和灵活，但是我最近开始怀念静态和结构化的语言，因为当时有一个同事让我对 Go 语言产生了兴趣。

我从写 JavaScript 到写 Go，我发现两种语言有很多相似之处。两者学习起来都很快并且易于上手，都具有充满表现力的语法，并且在开发者社区中都有很多工作机会。没有完美的编程语言，所以你应该总是选择一个适合手头项目的语言。在这篇文章中，我将要说明这两种语言深层次上的关键区别，希望能鼓励没有用过 Go 语言的用户可以有机会使用 Go 。

大体上的差异

在深入细节之前，我们应该先了解一下两种语言之间的重要区别。

Go，或称 Golang，是 Google 在 2007 年创建的自由开源编程语言。它以快速和简单为设计目标。Go 被直接编译成机器码，这就是它速度的来源。使用编译语言调试是相当容易的，因为你可以在早期捕获大量错误。Go 也是一种强类型的语言，它有助于数据完整，并可以在编译时查找类型错误。

另一方面，JavaScript 是一种弱类型语言。除了忽略验证数据的类型和真值判断陷阱所带来的额外负担之外，使用弱类型语言也有自己的好处。比起使用接口 interfaces 和范型 generics ，柯里化 currying 和可变的形参个数 flexible arity 让函数变得更加灵活。JavaScript 在运行时进行解释，这可能导致错误处理和调试的问题。Node 是一款基于 Google V8 虚拟机的 JavaScript 运行库，这使它成为一个轻量和快速的 Web 开发平台。

语法

作为原来的 JavaScript 开发者，Go 简单和直观的语法很吸引我。由于两种语言的语法可以说都是从 C 语言演变而来的，所以它们的语法有很多相同之处。Go 被普遍认为是一种“容易学习的语言”。那是因为它的对开发者友好的工具、精简的语法和固守惯例（LCTT 译注：惯例优先）。

Go 包含大量有助于简化开发的内置特性。你可以用标准 Go 构建工具把你的程序用 go build 命令编译成二进制可执行文件。使用内置的测试套件进行测试只需要运行 go test 即可。诸如原生支持的并发等特性甚至在语言层面上提供。

Google 的 Go 开发者认为，现在的编程太复杂了，太多的“记账一样，重复劳动和文书工作”。这就是为什么 Go 的语法被设计得如此简单和干净，以减少混乱、提高效率和增强可读性。它还鼓励开发人员编写明确的、易于理解的代码。Go 只有 25 个保留关键字和一种循环（for 循环），而不像 JavaScript 有大约 84 个关键字（包括保留关键字字、对象、属性和方法）。

为了说明语法的一些差异和相似之处，我们来看几个例子：

标点符号： Go 去除了所有多余的符号以提高效率和可读性。尽管 JavaScript 中需要符号的地方也不多（参见： Lisp），而且经常是可选的，但我更加喜欢 Go 的简单。

// JavaScript 的逗号和分号
for (var i = 0; i < 10; i++) {
console.log(i);
}

JavaScript 中的标点

// Go 使用最少数量标点
for i := 0; i < 10; i++ {
fmt.Println(i)
}

Go 中的标点

赋值：由于 Go 是强类型语言，所以你在初始化变量时可以使用 := 操作符来进行类型推断，以避免重复声明，而 JavaScript 则在运行时声明类型。

// JavaScript 赋值
var foo = "bar";

JavaScript 中的赋值

// Go 的赋值
var foo string //不使用类型推导
foo = "bar"
foo := "bar" //使用类型推导

Go 的赋值

导出：在 JavaScript 中，你必须从某个模块中显式地导出。在 Go 中，任何大写的函数将被默认导出。

const Bar = () => {};
module.exports = {
Bar
}

JavaScript 中的导出

// Go 中的导出
package foo // 定义包名
func Bar (s string) string {
// Bar 将被导出
}

Go 中的导出

导入：在 JavaScript 中 required 库是导入依赖项和模块所必需的，而 Go 则利用原生的 import 关键字通过包的路径导入模块。另一个区别是，与 Node 的中央 NPM 存储库不同，Go 使用 URL 作为路径来导入非标准库的包，这是为了从包的源码仓库直接克隆依赖。

// Javascript 的导入
var foo = require('foo');
foo.bar();

JavaScript 的导入

// Go 的导入
import (
"fmt" // Go 的标准库部分
"github.com/foo/foo" // 直接从仓库导入
)
foo.Bar()

Go 的导入

返回值：通过 Go 的多值返回特性可以优雅地传递和处理返回值和错误，并且通过传递引用减少了不正确的值传递。在 JavaScript 中需要通过一个对象或者数组来返回多个值。

// Javascript - 返回多值
function foo() {
return {a: 1, b: 2};
}
const { a, b } = foo();

JavaScript 的返回

// Go - 返回多值
func foo() (int, int) {
return 1, 2
}
a, b := foo()

Go 的返回

错误处理：Go 推荐在错误出现的地方捕获它们，而不是像 Node 一样在回调中让错误冒泡。

// Node 的错误处理
foo('bar', function(err, data) {
// 处理错误
}

JavaScript 的错误处理

//Go 的错误处理
foo, err := bar()
if err != nil {
// 用 defer、 panic、 recover 或 log.fatal 等等处理错误.
}

Go 的错误处理

可变参数函数：Go 和 JavaScript 的函数都支持传入不定数量的参数。

function foo (...args) {
console.log(args.length);
}
foo(); // 0
foo(1, 2, 3); // 3

JavaScript 中的可变参数函数

func foo (args ...int) {
fmt.Println(len(args))
}
func main() {
foo() // 0
foo(1,2,3) // 3
}

Go 中的可变参数函数

社区

当比较 Go 和 Node 提供的编程范式哪种更方便时，两边都有不同的拥护者。Node 在软件包数量和社区的大小上完全胜过了 Go。Node 包管理器（NPM），是世界上最大的软件仓库，拥有超过 410,000 个软件包，每天以 555 个新软件包的惊人速度增长。这个数字可能看起来令人吃惊（确实是），但是需要注意的是，这些包许多是重复的，且质量不足以用在生产环境。相比之下，Go 大约有 13 万个包。

Node 和 Go 包的数量

尽管 Node 和 Go 岁数相仿，但 JavaScript 使用更加广泛，并拥有巨大的开发者和开源社区。因为 Node 是为所有人开发的，并在开始的时候就带有一个强壮的包管理器，而 Go 是特地为 Google 开发的。下面的Spectrum 排行榜显示了当前流行的的顶尖 Web 开发语言。

Web 开发语言排行榜前 7 名

JavaScript 的受欢迎程度近年来似乎保持相对稳定，而 Go 一直在保持上升趋势。

编程语言趋势

性能

如果你的主要关注点是速度呢？当今似乎人们比以前更重视性能的优化。用户不喜欢等待信息。事实上，如果网页的加载时间超过 3 秒，40％的用户会放弃访问您的网站。

因为它的非阻塞异步 I/O，Node 经常被认为是高性能的语言。另外，正如我之前提到的，Node 运行在针对动态语言进行了优化的 Google V8 引擎上。而 Go 的设计也考虑到速度。Google 的开发者们通过建立了一个“充满表现力而轻量级的类型系统；并发和垃圾回收机制；强制地指定依赖版本等等”，达成了这一目标。

我运行了一些测试来比较 Node 和 Go 之间的性能。这些测试注重于语言提供的初级能力。如果我准备测试例如 HTTP 请求或者 CPU 密集型运算，我会使用 Go 语言级别的并发工具（goroutines/channels）。但是我更注重于各个语言提供的基本特性（参见三种并发方法了解关于 goroutines 和 channels 的更多知识）。

我在基准测试中也加入了 Python，所以无论如何我们对 Node 和 Go 的结果都很满意。

循环/算术

迭代十亿项并把它们相加：

var r = 0;
for (var c = 0; c < 1000000000; c++) {
    r += c;
}

Node

package main
func main() {
    var r int
    for c := 0; c < 1000000000; c++ {
        r += c
    }
}

sum(xrange(1000000000))

Python

结果

这里的输家无疑是 Python，花了超过 7 秒的 CPU 时间。而 Node 和 Go 都相当高效，分别用了 900 ms 和 408 ms。

修正：由于一些评论表明 Python 的性能还可以提高。我更新了结果来反映这些变化。同时，使用 PyPy 大大地提高了性能。当使用 Python 3.6.1 和 PyPy 3.5.7 运行时，性能提升到 1.234 秒，但仍然不及 Go 和 Node 。

I/O

遍历一百万个数字并将其写入一个文件。

var fs = require('fs');
var wstream = fs.createWriteStream('node');

for (var c = 0; c < 1000000; ++c) {
  wstream.write(c.toString());
}
wstream.end();

Node

package main

import (
    "bufio"
    "os"
    "strconv"
)

func main() {
    file, _ := os.Create("go")
    b := bufio.NewWriter(file)
    for c := 0; c < 1000000; c++ {
        num := strconv.Itoa(c)
        b.WriteString(num)
    }
    file.Close()
}

with open("python", "a") as text_file:
    for i in range(1000000):
        text_file.write(str(i))

Python

结果

Python 以 7.82 秒再次排名第三。这次测试中，Node 和 Go 之间的差距很大，Node 花费大约 1.172 秒，Go 花费了 213 毫秒。真正令人印象深刻的是，Go 大部分的处理时间花费在编译上。如果我们将代码编译，以二进制运行，这个 I/O 测试仅花费 78 毫秒——要比 Node 快 15 倍。

修正：修改了 Go 代码以实现缓存 I/O。

冒泡排序

将含有十个元素的数组排序一千万次。

function bubbleSort(input) {
    var n = input.length;
    var swapped = true;
    while (swapped) {
        swapped = false;
        for (var i = 0; i < n; i++) {
            if (input[i - 1] > input [i]) {
                [input[i], input[i - 1]] = [input[i - 1], input[i]];
                swapped = true;
            }
        }
    }
}

for (var c = 0; c < 1000000; c++) {
    const toBeSorted = [1, 3, 2, 4, 8, 6, 7, 2, 3, 0];
    bubbleSort(toBeSorted);
}

Node

package main

var toBeSorted [10]int = [10]int{1, 3, 2, 4, 8, 6, 7, 2, 3, 0}

func bubbleSort(input [10]int) {
    n := len(input)
    swapped := true
    for swapped {
        swapped = false
        for i := 1; i < n; i++ {
            if input[i-1] > input[i] {
                input[i], input[i-1] = input[i-1], input[i]
                swapped = true
            }
        }
    }
}

func main() {
    for c := 0; c < 1000000; c++ {
        bubbleSort(toBeSorted)
    }
}

def bubbleSort(input):
    length = len(input)
    swapped = True

    while swapped:
        swapped = False
        for i in range(1,length):
            if input[i - 1] > input[i]:
                input[i], input[i - 1] = input[i - 1], input[i]
                swapped = True

for i in range(1000000):
    toBeSorted = [1, 3, 2, 4, 8, 6, 7, 2, 3, 0]
    bubbleSort(toBeSorted)

Python

结果

像刚才一样，Python 的表现是最差的，大约花费 15 秒完成了任务。 Go 完成任务的速度是 Node 的 16 倍。

判决

Go 无疑是这三个测试中的赢家，而 Node 大部分表现都很出色。Python 也表现不错。要清楚，性能不是选择编程语言需要考虑的全部内容。如果您的应用不需要处理大量数据，那么 Node 和 Go 之间的性能差异可能是微不足道的。有关性能的一些其他比较，请参阅以下内容：

结论

这个帖子不是为了证明一种语言比另一种语言更好。由于各种原因，每种编程语言都在软件开发社区中占有一席之地。我的意图是强调 Go 和 Node 之间的差异，并且促进展示一种新的 Web 开发语言。在为一个项目选择语言时，有各种因素需要考虑，比如开发人员的熟悉程度、花费和实用性。我鼓励在决定哪种语言适合您时进行一次彻底的底层分析。

正如我们所看到的，Go 有如下的优点：接近底层语言的性能，简单的语法和相对简单的学习曲线使它成为构建可拓展和安全的 Web 应用的理想选择。随着 Go 的使用率和社区活动的快速增长，它将会成为现代网络开发中的重要角色。话虽如此，我相信如果 Node 被正确地实现，它正在向正确的方向努力，仍然是一种强大而有用的语言。它具有大量的追随者和活跃的社区，使其成为一个简单的平台，可以让 Web 应用在任何时候启动和运行。

资料

如果你对学习 Go 语言感兴趣，可以参阅下面的资源：

via: https://medium.com/xo-tech/from-node-to-go-a-high-level-comparison-56c8b717324a#.byltlz535

作者：John Stamatakos 译者：trnhoe 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

探索传统 JavaScript 基准测试

Benedikt Meurer 发布于 2017-09-29
另请参阅: 软件开发,Javascript, 基准测试
评论

可以很公平地说，JavaScript 是当下软件工程中最重要的技术。对于那些深入接触过编程语言、编译器和虚拟机的人来说，这仍然有点令人惊讶，因为在语言设计者们看来，JavaScript 不是十分优雅；在编译器工程师们看来，它没有多少可优化的地方；甚至还没有一个伟大的标准库。这取决于你和谁吐槽，JavaScript 的缺点你花上数周都枚举不完，而你总会找到一些你从所未知的奇怪的东西。尽管这看起来明显困难重重，不过 JavaScript 还是成为了当今 web 的核心，并且还（通过 Node.js）成为服务器端和云端的主导技术，甚至还开辟了进军物联网领域的道路。

那么问题来了，为什么 JavaScript 如此受欢迎？或者说如此成功？我知道没有一个很好的答案。如今我们有许多使用 JavaScript 的好理由，或许最重要的是围绕其构建的庞大的生态系统，以及现今大量可用的资源。但所有这一切实际上是发展到一定程度的后果。为什么 JavaScript 变得流行起来了？嗯，你或许会说，这是 web 多年来的通用语了。但是在很长一段时间里，人们极其讨厌 JavaScript。回顾过去，似乎第一波 JavaScript 浪潮爆发在上个年代的后半段。那个时候 JavaScript 引擎加速了各种不同的任务的执行，很自然的，这可能让很多人对 JavaScript 刮目相看。

回到过去那些日子，这些加速使用了现在所谓的传统 JavaScript 基准进行测试——从苹果的 SunSpider 基准（JavaScript 微基准之母）到 Mozilla 的 Kraken 基准和谷歌的 V8 基准。后来，V8 基准被 Octane 基准取代，而苹果发布了新的 JetStream 基准。这些传统的 JavaScript 基准测试驱动了无数人的努力，使 JavaScript 的性能达到了本世纪初没人能预料到的水平。据报道其性能加速达到了 1000 倍，一夜之间在网站使用 <script> 标签不再是与魔鬼共舞，做客户端不再仅仅是可能的了，甚至是被鼓励的。

（来源： Advanced JS performance with V8 and Web Assembly， Chrome Developer Summit 2016, @s3ththompson。）

现在是 2016 年，所有（相关的）JavaScript 引擎的性能都达到了一个令人难以置信的水平，web 应用像原生应用一样快（或者能够像原生应用一样快）。引擎配有复杂的优化编译器，通过收集之前的关于类型/形状的反馈来推测某些操作（例如属性访问、二进制操作、比较、调用等），生成高度优化的机器代码的短序列。大多数优化是由 SunSpider 或 Kraken 等微基准以及 Octane 和 JetStream 等静态测试套件驱动的。由于有像 asm.js 和 Emscripten 这样的 JavaScript 技术，我们甚至可以将大型 C++ 应用程序编译成 JavaScript，并在你的浏览器上运行，而无需下载或安装任何东西。例如，现在你可以在 web 上玩 AngryBots，无需沙盒，而过去的 web 游戏需要安装一堆诸如 Adobe Flash 或 Chrome PNaCl 的特殊插件。

这些成就绝大多数都要归功于这些微基准和静态性能测试套件的出现，以及与这些传统的 JavaScript 基准间的竞争的结果。你可以对 SunSpider 表示不满，但很显然，没有 SunSpider，JavaScript 的性能可能达不到今天的高度。好吧，赞美到此为止。现在看看另一方面，所有的静态性能测试——无论是微基准 micro-benchmark 还是大型应用的宏基准 macro-benchmark ，都注定要随着时间的推移变成噩梦！为什么？因为在开始摆弄它之前，基准只能教你这么多。一旦达到某个阔值以上（或以下），那么有益于特定基准的优化的一般适用性将呈指数级下降。例如，我们将 Octane 作为现实世界中 web 应用性能的代表，并且在相当长的一段时间里，它可能做得很不错，但是现在，Octane 与现实场景中的时间分布是截然不同的，因此即使眼下再优化 Octane 乃至超越自身，可能在现实世界中还是得不到任何显著的改进（无论是通用 web 还是 Node.js 的工作负载）。

（来源：Real-World JavaScript Performance，BlinkOn 6 conference，@tverwaes）

由于传统 JavaScript 基准（包括最新版的 JetStream 和 Octane）可能已经背离其有用性变得越来越远，我们开始在 2016 年初寻找新的方法来测量现实场景的性能，为 V8 和 Chrome 添加了大量新的性能追踪钩子。我们还特意添加一些机制来查看我们在浏览 web 时的时间究竟开销在哪里，例如，是脚本执行、垃圾回收、编译，还是什么地方？而这些调查的结果非常有趣和令人惊讶。从上面的幻灯片可以看出，运行 Octane 花费了 70% 以上的时间去执行 JavaScript 和垃圾回收，而浏览 web 的时候，通常执行 JavaScript 花费的时间不到 30%，垃圾回收占用的时间永远不会超过 5%。在 Octane 中并没有体现出它花费了大量时间来解析和编译。因此，将更多的时间用在优化 JavaScript 执行上将提高你的 Octane 跑分，但不会对加载 youtube.com 有任何积极的影响。事实上，花费更多的时间来优化 JavaScript 执行甚至可能有损你现实场景的性能，因为编译器需要更多的时间，或者你需要跟踪更多的反馈，最终在编译、垃圾回收和运行时桶 Runtime bucket 等方面开销了更多的时间。

还有另外一组基准测试用于测量浏览器整体性能（包括 JavaScript 和 DOM 性能），最新推出的是 Speedometer 基准。该基准试图通过运行一个用不同的主流 web 框架实现的简单的 TodoMVC 应用（现在看来有点过时了，不过新版本正在研发中）以捕获更真实的现实场景的性能。上述幻灯片中的各种测试（Angular、Ember、React、Vanilla、Flight 和 Backbone）挨着放在 Octane 之后，你可以看到，此时此刻这些测试似乎更好地代表了现实世界的性能指标。但是请注意，这些数据收集在本文撰写将近 6 个月以前，而且我们优化了更多的现实场景模式（例如我们正在重构垃圾回收系统以显著地降低开销，并且解析器也正在重新设计）。还要注意的是，虽然这看起来像是只和浏览器相关，但我们有非常强有力的证据表明传统的峰值性能基准也不能很好的代表现实场景中 Node.js 应用性能。

（来源： Real-World JavaScript Performance， BlinkOn 6 conference, @tverwaes.）

所有这一切可能已经路人皆知了，因此我将用本文剩下的部分强调一些具体案例，它们对关于我为什么认为这不仅有用，而且必须停止关注某一阈值的静态峰值性能基准测试对于 JavaScript 社区的健康是很关键的。让我通过一些例子说明 JavaScript 引擎怎样来玩弄基准的。

臭名昭著的 SunSpider 案例

一篇关于传统 JavaScript 基准测试的博客如果没有指出 SunSpider 那个明显的问题是不完整的。让我们从性能测试的最佳实践开始，它在现实场景中不是很适用：bitops-bitwise-and.js 性能测试。

有一些算法需要进行快速的 AND 位运算，特别是从 C/C++ 转译成 JavaScript 的地方，所以快速执行该操作确实有点意义。然而，现实场景中的网页可能不关心引擎在循环中执行 AND 位运算是否比另一个引擎快两倍。但是再盯着这段代码几秒钟后，你可能会注意到在第一次循环迭代之后 bitwiseAndValue 将变成 0，并且在接下来的 599999 次迭代中将保持为 0。所以一旦你让此获得了好的性能，比如在差不多的硬件上所有测试均低于 5ms，在经过尝试之后你会意识到，只有循环的第一次是必要的，而剩余的迭代只是在浪费时间（例如 loop peeling 后面的死代码），那你现在就可以开始玩弄这个基准测试了。这需要 JavaScript 中的一些机制来执行这种转换，即你需要检查 bitwiseAndValue 是全局对象的常规属性还是在执行脚本之前不存在，全局对象或者它的原型上必须没有拦截器。但如果你真的想要赢得这个基准测试，并且你愿意全力以赴，那么你可以在不到 1ms 的时间内完成这个测试。然而，这种优化将局限于这种特殊情况，并且测试的轻微修改可能不再触发它。

好吧，那么 bitops-bitwise-and.js 测试彻底肯定是微基准最失败的案例。让我们继续转移到 SunSpider 中更逼真的场景——string-tagcloud.js 测试，它基本上是运行一个较早版本的 json.js polyfill。该测试可以说看起来比位运算测试更合理，但是花点时间查看基准的配置之后立刻会发现：大量的时间浪费在一条 eval 表达式（高达 20% 的总执行时间被用于解析和编译，再加上实际执行编译后代码的 10% 的时间）。

仔细看看，这个 eval 只执行了一次，并传递一个 JSON 格式的字符串，它包含一个由 2501 个含有 tag 和 popularity 属性的对象组成的数组：

([
  {
    "tag": "titillation",
    "popularity": 4294967296
  },
  {
    "tag": "foamless",
    "popularity": 1257718401
  },
  {
    "tag": "snarler",
    "popularity": 613166183
  },
  {
    "tag": "multangularness",
    "popularity": 368304452任何
  },
  {
    "tag": "Fesapo unventurous",
    "popularity": 248026512
  },
  {
    "tag": "esthesioblast",
    "popularity": 179556755
  },
  {
    "tag": "echeneidoid",
    "popularity": 136641578
  },
  {
    "tag": "embryoctony",
    "popularity": 107852576
  },
  ...
])

显然，解析这些对象字面量，为其生成本地代码，然后执行该代码的成本很高。将输入的字符串解析为 JSON 并生成适当的对象图的开销将更加低廉。所以，加快这个基准测试的一个小把戏就是模拟 eval，并尝试总是将数据首先作为 JSON 解析，如果以 JSON 方式读取失败，才回退进行真实的解析、编译、执行（尽管需要一些额外的黑魔法来跳过括号）。早在 2007 年，这甚至不算是一个坏点子，因为没有 JSON.parse，不过在 2017 年这只是 JavaScript 引擎的技术债，可能会让 eval 的合法使用遥遥无期。

--- string-tagcloud.js.ORIG     2016-12-14 09:00:52.869887104 +0100
+++ string-tagcloud.js  2016-12-14 09:01:01.033944051 +0100
@@ -198,7 +198,7 @@
                     replace(/"[^"\\\n\r]*"|true|false|null|-?\d+(?:\.\d*)?(:?[eE][+\-]?\d+)?/g, ']').
                     replace(/(?:^|:|,)(?:\s*\[)+/g, ''))) {

-                j = eval('(' + this + ')');
+                j = JSON.parse(this);

                 return typeof filter === 'function' ? walk('', j) : j;
             }

事实上，将基准测试更新到现代 JavaScript 会立刻会性能暴增，正如今天的 V8 LKGR 从 36ms 降到了 26ms，性能足足提升了 30%！

$ node string-tagcloud.js.ORIG
Time (string-tagcloud): 36 ms.
$ node string-tagcloud.js
Time (string-tagcloud): 26 ms.
$ node -v
v8.0.0-pre
$

这是静态基准和性能测试套件常见的一个问题。今天，没有人会正儿八经地用 eval 解析 JSON 数据（不仅是因为性能问题，还出于严重的安全性考虑），而是坚持为最近五年写的代码使用 JSON.parse。事实上，使用 eval 解析 JSON 可能会被视作产品级代码的的一个漏洞！所以引擎作者致力于新代码的性能所作的努力并没有反映在这个古老的基准中，相反地，而是使得 eval 不必要地~~更智能~~复杂化，从而赢得 string-tagcloud.js 测试。

好吧，让我们看看另一个例子：3d-cube.js。这个基准测试做了很多矩阵运算，即便是最聪明的编译器对此也无可奈何，只能说执行而已。基本上，该基准测试花了大量的时间执行 Loop 函数及其调用的函数。

一个有趣的发现是：RotateX、RotateY 和 RotateZ 函数总是调用相同的常量参数 Phi。

这意味着我们基本上总是为 Math.sin 和 Math.cos 计算相同的值，每次执行都要计算 204 次。只有 3 个不同的输入值：

0.017453292519943295
0.05235987755982989
0.08726646259971647

显然，你可以在这里做的一件事情就是通过缓存以前的计算值来避免重复计算相同的正弦值和余弦值。事实上，这是 V8 以前的做法，而其它引擎例如 SpiderMonkey 目前仍然在这样做。我们从 V8 中删除了所谓的超载缓存 transcendental cache ，因为缓存的开销在实际的工作负载中是不可忽视的，你不可能总是在一行代码中计算相同的值，这在其它地方倒不稀奇。当我们在 2013 和 2014 年移除这个特定的基准优化时，我们对 SunSpider 基准产生了强烈的冲击，但我们完全相信，为基准而优化并没有任何意义，并同时以这种方式批判了现实场景中的使用案例。

（来源：arewefastyet.com）

显然，处理恒定正弦/余弦输入的更好的方法是一个内联的启发式算法，它试图平衡内联因素与其它不同的因素，例如在调用位置优先选择内联，其中常量叠算 constant folding 可以是有益的，例如在 RotateX、RotateY 和 RotateZ 调用位置的案例中。但是出于各种原因，这对于 Crankshaft 编译器并不可行。使用 Ignition 和 TurboFan 倒是一个明智的选择，我们已经在开发更好的内联启发式算法。

垃圾回收（GC）是有害的

除了这些非常具体的测试问题，SunSpider 基准测试还有一个根本性的问题：总体执行时间。目前 V8 在适当的英特尔硬件上运行整个基准测试大概只需要 200ms（使用默认配置）。次垃圾回收 minor GC 在 1ms 到 25ms 之间（取决于新空间中的存活对象和旧空间的碎片），而主垃圾回收 major GC 暂停的话可以轻松减掉 30ms（甚至不考虑增量标记的开销），这超过了 SunSpider 套件总体执行时间的 10%！因此，任何不想因垃圾回收循环而造成减速 10-20% 的引擎，必须用某种方式确保它在运行 SunSpider 时不会触发垃圾回收。

就实现而言，有不同的方案，不过就我所知，没有一个在现实场景中产生了任何积极的影响。V8 使用了一个相当简单的技巧：由于每个 SunSpider 套件都运行在一个新的 <iframe> 中，这对应于 V8 中一个新的本地上下文，我们只需检测快速的 <iframe> 创建和处理（所有的 SunSpider 测试每个花费的时间小于 50ms），在这种情况下，在处理和创建之间执行垃圾回收，以确保我们在实际运行测试的时候不会触发垃圾回收。这个技巧运行的很好，在 99.9% 的案例中没有与实际用途冲突；除了时不时的你可能会受到打击，不管出于什么原因，如果你做的事情让你看起来像是 V8 的 SunSpider 测试驱动程序，你就可能被强制的垃圾回收打击到，这有可能对你的应用导致负面影响。所以谨记一点：不要让你的应用看起来像 SunSpider！

我可以继续展示更多 SunSpider 示例，但我不认为这非常有用。到目前为止，应该清楚的是，为刷新 SunSpider 评分而做的进一步优化在现实场景中没有带来任何好处。事实上，世界可能会因为没有 SunSpider 而更美好，因为引擎可以放弃只是用于 SunSpider 的奇淫技巧，或者甚至可以伤害到现实中的用例。不幸的是，SunSpider 仍然被（科技）媒体大量地用来比较他们眼中的浏览器性能，或者甚至用来比较手机！所以手机制造商和安卓制造商对于让 SunSpider（以及其它现在毫无意义的基准 FWIW）上的 Chrome 看起来比较体面自然有一定的兴趣。手机制造商通过销售手机来赚钱，所以获得良好的评价对于电话部门甚至整间公司的成功至关重要。其中一些部门甚至在其手机中配置在 SunSpider 中得分较高的旧版 V8，将他们的用户置于各种未修复的安全漏洞之下（在新版中早已被修复），而让用户被最新版本的 V8 带来的任何现实场景的性能优势拒之门外！

（来源：www.engadget.com）

作为 JavaScript 社区的一员，如果我们真的想认真对待 JavaScript 领域的现实场景的性能，我们需要让各大技术媒体停止使用传统的 JavaScript 基准来比较浏览器或手机。能够在每个浏览器中运行一个基准测试，并比较它的得分自然是好的，但是请使用一个与当今世界相关的基准，例如真实的 web 页面；如果你觉得需要通过浏览器基准来比较两部手机，请至少考虑使用 Speedometer。

轻松一刻

我一直很喜欢这个 Myles Borins 谈话，所以我不得不无耻地向他偷师。现在我们从 SunSpider 的谴责中回过头来，让我们继续检查其它经典基准。

不是那么显眼的 Kraken 案例

Kraken 基准是 Mozilla 于 2010 年 9 月发布的，据说它包含了现实场景应用的片段/内核，并且与 SunSpider 相比少了一个微基准。我不想在 Kraken 上花太多口舌，因为我认为它不像 SunSpider 和 Octane 一样对 JavaScript 性能有着深远的影响，所以我将强调一个特别的案例——audio-oscillator.js 测试。

正如你所见，测试调用了 calcOsc 函数 500 次。calcOsc 首先在全局的 sine Oscillator 上调用 generate，然后创建一个新的 Oscillator，调用它的 generate 方法并将其添加到全局的 sine Oscillator 里。没有详细说明测试为什么是这样做的，让我们看看 Oscillator 原型上的 generate 方法。

让我们看看代码，你也许会觉得这里主要是循环中的数组访问或者乘法或者 Math.round 调用，但令人惊讶的是 offset % this.waveTableLength 表达式完全支配了 Oscillator.prototype.generate 的运行。在任何的英特尔机器上的分析器中运行此基准测试显示，超过 20% 的时间占用都属于我们为模数生成的 idiv 指令。然而一个有趣的发现是，Oscillator 实例的 waveTableLength 字段总是包含相同的值——2048，因为它在 Oscillator 构造器中只分配一次。

如果我们知道整数模数运算的右边是 2 的幂，我们显然可以生成更好的代码，完全避免了英特尔上的 idiv 指令。所以我们需要获取一种信息使 this.waveTableLength 从 Oscillator 构造器到 Oscillator.prototype.generate 中的模运算都是 2048。一个显而易见的方法是尝试依赖于将所有内容内嵌到 calcOsc 函数，并让 load/store 消除为我们进行的常量传播，但这对于在 calcOsc 函数之外分配的 sine oscillator 无效。

因此，我们所做的就是添加支持跟踪某些常数值作为模运算符的右侧反馈。这在 V8 中是有意义的，因为我们为诸如 +、* 和 % 的二进制操作跟踪类型反馈，这意味着操作者跟踪输入的类型和产生的输出类型（参见最近的圆桌讨论中关于动态语言的快速运算的幻灯片）。当然，用 fullcodegen 和 Crankshaft 挂接起来也是相当容易的，MOD 的 BinaryOpIC 也可以跟踪右边已知的 2 的冥。

$ ~/Projects/v8/out/Release/d8 --trace-ic audio-oscillator.js
[...SNIP...]
[BinaryOpIC(MOD:None*None->None) => (MOD:Smi*2048->Smi) @ ~Oscillator.generate+598 at audio-oscillator.js:697]
[...SNIP...]
$

事实上，以默认配置运行的 V8 （带有 Crankshaft 和 fullcodegen）表明 BinaryOpIC 正在为模数的右侧拾取适当的恒定反馈，并正确跟踪左侧始终是一个小整数（以 V8 的话叫做 Smi），我们也总是产生一个小整数结果。使用 --print-opt-code -code-comments 查看生成的代码，很快就显示出，Crankshaft 利用反馈在 Oscillator.prototype.generate 中为整数模数生成一个有效的代码序列：

[...SNIP...]
                  ;;; <@80,#84> load-named-field
0x133a0bdacc4a   330  8b4343         movl rax,[rbx+0x43]
                  ;;; <@83,#86> compare-numeric-and-branch
0x133a0bdacc4d   333  3d00080000     cmp rax,0x800
0x133a0bdacc52   338  0f85ff000000   jnz 599  (0x133a0bdacd57)
[...SNIP...]
                  ;;; <@90,#94> mod-by-power-of-2-i
0x133a0bdacc5b   347  4585db         testl r11,r11
0x133a0bdacc5e   350  790f           jns 367  (0x133a0bdacc6f)
0x133a0bdacc60   352  41f7db         negl r11
0x133a0bdacc63   355  4181e3ff070000 andl r11,0x7ff
0x133a0bdacc6a   362  41f7db         negl r11
0x133a0bdacc6d   365  eb07           jmp 374  (0x133a0bdacc76)
0x133a0bdacc6f   367  4181e3ff070000 andl r11,0x7ff
[...SNIP...]
                  ;;; <@127,#88> deoptimize
0x133a0bdacd57   599  e81273cdff     call 0x133a0ba8406e
[...SNIP...]

所以你看到我们加载 this.waveTableLength（rbx 持有 this 的引用）的值，检查它仍然是 2048（十六进制的 0x800），如果是这样，就只用适当的掩码 0x7ff（r11 包含循环感应变量 i 的值）执行一个位操作 AND ，而不是使用 idiv 指令（注意保留左侧的符号）。

过度特定的问题

所以这个技巧酷毙了，但正如许多基准关注的技巧都有一个主要的缺点：太过于特定了！一旦右侧发生变化，所有优化过的代码就失去了优化（假设右手始终是不再处理的 2 的冥），任何进一步的优化尝试都必须再次使用 idiv，因为 BinaryOpIC 很可能以 Smi * Smi -> Smi 的形式报告反馈。例如，假设我们实例化另一个 Oscillator，在其上设置不同的 waveTableLength，并为 Oscillator 调用 generate，那么即使我们实际上感兴趣的 Oscillator 不受影响，我们也会损失 20% 的性能（例如，引擎在这里实行非局部惩罚）。

--- audio-oscillator.js.ORIG    2016-12-15 22:01:43.897033156 +0100
+++ audio-oscillator.js 2016-12-15 22:02:26.397326067 +0100
@@ -1931,6 +1931,10 @@
 var frequency = 344.53;
 var sine = new Oscillator(Oscillator.Sine, frequency, 1, bufferSize, sampleRate);

+var unused = new Oscillator(Oscillator.Sine, frequency, 1, bufferSize, sampleRate);
+unused.waveTableLength = 1024;
+unused.generate();
+
 var calcOsc = function() {
   sine.generate();

将原始的 audio-oscillator.js 执行时间与包含额外未使用的 Oscillator 实例与修改的 waveTableLength 的版本进行比较，显示的是预期的结果：

$ ~/Projects/v8/out/Release/d8 audio-oscillator.js.ORIG
Time (audio-oscillator-once): 64 ms.
$ ~/Projects/v8/out/Release/d8 audio-oscillator.js
Time (audio-oscillator-once): 81 ms.
$

这是一个非常可怕的性能悬崖的例子：假设开发人员编写代码库，并使用某些样本输入值进行仔细的调整和优化，性能是体面的。现在，用户读过了性能说明开始使用该库，但不知何故从性能悬崖下降，因为她/他正在以一种稍微不同的方式使用库，即特定的 BinaryOpIC 的某种污染方式的类型反馈，并且遭受 20% 的减速（与该库作者的测量相比），该库的作者和用户都无法解释，这似乎是随机的。

现在这种情况在 JavaScript 领域并不少见，不幸的是，这些悬崖中有几个是不可避免的，因为它们是由于 JavaScript 的性能是基于乐观的假设和猜测。我们已经花了大量时间和精力来试图找到避免这些性能悬崖的方法，而仍提供了（几乎）相同的性能。事实证明，尽可能避免 idiv 是很有意义的，即使你不一定知道右边总是一个 2 的幂（通过动态反馈），所以为什么 TurboFan 的做法有异于 Crankshaft 的做法，因为它总是在运行时检查输入是否是 2 的幂，所以一般情况下，对于有符整数模数，优化右手侧的（未知的） 2 的冥看起来像这样（伪代码）：

if 0 < rhs then
  msk = rhs - 1
  if rhs & msk != 0 then
    lhs % rhs
  else
    if lhs < 0 then
      -(-lhs & msk)
    else
      lhs & msk
else
  if rhs < -1 then
    lhs % rhs
  else
    zero

这产生更加一致和可预测的性能（使用 TurboFan）：

$ ~/Projects/v8/out/Release/d8 --turbo audio-oscillator.js.ORIG
Time (audio-oscillator-once): 69 ms.
$ ~/Projects/v8/out/Release/d8 --turbo audio-oscillator.js
Time (audio-oscillator-once): 69 ms.
$

基准和过度特定化的问题在于基准可以给你提示可以看看哪里以及该怎么做，但它不告诉你应该做到什么程度，不能保护合理优化。例如，所有 JavaScript 引擎都使用基准来防止性能回退，但是运行 Kraken 不能保护我们在 TurboFan 中使用的常规方法，即我们可以将 TurboFan 中的模优化降级到过度特定的版本的 Crankshaft，而基准不会告诉我们性能回退的事实，因为从基准的角度来看这很好！现在你可以扩展基准，也许以上面我们相同的方式，并试图用基准覆盖一切，这是引擎实现者在一定程度上做的事情，但这种方法不能任意缩放。即使基准测试方便，易于用来沟通和竞争，以常识所见你还是需要留下空间，否则过度特定化将支配一切，你会有一个真正的、非常好的可接受的性能，以及巨大的性能悬崖线。

Kraken 测试还有许多其它的问题，不过现在让我们继续讨论过去五年中最有影响力的 JavaScript 基准测试—— Octane 测试。

深入接触 Octane

Octane 基准是 V8 基准的继承者，最初由谷歌于 2012 年中期发布，目前的版本 Octane 2.0 于 2013 年年底发布。这个版本包含 15 个独立测试，其中对于 Splay 和 Mandreel，我们用来测试吞吐量和延迟。这些测试范围从微软 TypeScript 编译器编译自身到 zlib 测试测量原生的 asm.js 性能，再到 RegExp 引擎的性能测试、光线追踪器、2D 物理引擎等。有关各个基准测试项的详细概述，请参阅说明书。所有这些测试项目都经过仔细的筛选，以反映 JavaScript 性能的方方面面，我们认为这在 2012 年非常重要，或许预计在不久的将来会变得更加重要。

在很大程度上 Octane 在实现其将 JavaScript 性能提高到更高水平的目标方面无比的成功，它在 2012 年和 2013 年引导了良性的竞争，Octane 创造了巨大的业绩和成就。但是现在将近 2017 年了，世界看起来与 2012 年真的迥然不同了。除了通常和经常被引用的批评，Octane 中的大多数项目基本上已经过时（例如，老版本的 TypeScript，zlib 通过老版本的 Emscripten 编译而成，Mandreel 甚至不再可用等等），某种更重要的方式影响了 Octane 的用途：

我们看到大型 web 框架赢得了 web 种族之争，尤其是像 Ember 和 AngularJS 这样的重型框架，它们使用了 JavaScript 执行模式，不过根本没有被 Octane 所反映，并且经常受到（我们）Octane 具体优化的损害。我们还看到 JavaScript 在服务器和工具前端获胜，这意味着有大规模的 JavaScript 应用现在通常运行上数星期，如果不是运行上数年都不会被 Octane 捕获。正如开篇所述，我们有硬数据表明 Octane 的执行和内存配置文件与我们每天在 web 上看到的截然不同。

让我们来看看今天一些玩弄 Octane 基准的具体例子，其中优化不再反映在现实场景。请注意，即使这可能听起来有点负面回顾，它绝对不意味着这样！正如我已经说过好几遍，Octane 是 JavaScript 性能故事中的重要一章，它发挥了至关重要的作用。在过去由 Octane 驱动的 JavaScript 引擎中的所有优化都是善意地添加的，因为 Octane 是现实场景性能的好代理！每个年代都有它的基准，而对于每一个基准都有一段时间你必须要放手！

话虽如此，让我们在路上看这个节目，首先看看 Box2D 测试，它是基于 Box2DWeb （一个最初由 Erin Catto 编写的移植到 JavaScript 的流行的 2D 物理引擎）的。总的来说，很多浮点数学驱动了很多 JavaScript 引擎下很好的优化，但是，事实证明它包含一个可以肆意玩弄基准的漏洞（怪我，我发现了漏洞，并添加在这种情况下的漏洞）。在基准中有一个函数 D.prototype.UpdatePairs，看起来像这样：

D.prototype.UpdatePairs = function(b) {
    var e = this;
    var f = e.m_pairCount = 0,
        m;
    for (f = 0; f < e.m_moveBuffer.length; ++f) {
        m = e.m_moveBuffer[f];
        var r = e.m_tree.GetFatAABB(m);
        e.m_tree.Query(function(t) {
                if (t == m) return true;
                if (e.m_pairCount == e.m_pairBuffer.length) e.m_pairBuffer[e.m_pairCount] = new O;
                var x = e.m_pairBuffer[e.m_pairCount];
                x.proxyA = t < m ? t : m;
                x.proxyB = t >= m ? t : m;
                ++e.m_pairCount;
                return true
            },
            r)
    }
    for (f = e.m_moveBuffer.length = 0; f < e.m_pairCount;) {
        r = e.m_pairBuffer[f];
        var s = e.m_tree.GetUserData(r.proxyA),
            v = e.m_tree.GetUserData(r.proxyB);
        b(s, v);
        for (++f; f < e.m_pairCount;) {
            s = e.m_pairBuffer[f];
            if (s.proxyA != r.proxyA || s.proxyB != r.proxyB) break;
            ++f
        }
    }
};

一些分析显示，在第一个循环中传递给 e.m_tree.Query 的无辜的内部函数花费了大量的时间：

function(t) {
    if (t == m) return true;
    if (e.m_pairCount == e.m_pairBuffer.length) e.m_pairBuffer[e.m_pairCount] = new O;
    var x = e.m_pairBuffer[e.m_pairCount];
    x.proxyA = t < m ? t : m;
    x.proxyB = t >= m ? t : m;
    ++e.m_pairCount;
    return true
}

更准确地说，时间并不是开销在这个函数本身，而是由此触发的操作和内置库函数。结果，我们花费了基准调用的总体执行时间的 4-7% 在 Compare` 运行时函数上，它实现了抽象关系比较的一般情况。

Box2D 比较分析

几乎所有对运行时函数的调用都来自 CompareICStub，它用于内部函数中的两个关系比较：

x.proxyA = t < m ? t : m;
x.proxyB = t >= m ? t : m;

所以这两行无辜的代码要负起 99% 的时间开销的责任！这怎么来的？好吧，与 JavaScript 中的许多东西一样，抽象关系比较的直观用法不一定是正确的。在这个函数中，t 和 m 都是 L 的实例，它是这个应用的一个中心类，但不会覆盖 Symbol.toPrimitive、“toString”、“valueOf” 或 Symbol.toStringTag 属性，它们与抽象关系比较相关。所以如果你写 t < m 会发生什么呢？

调用 ToPrimitive(t, hint Number)。
运行 OrdinaryToPrimitive(t, "number")，因为这里没有 Symbol.toPrimitive。
执行 t.valueOf()，这会获得 t 自身的值，因为它调用了默认的 Object.prototype.valueOf。
接着执行 t.toString()，这会生成 "[object Object]"，因为调用了默认的 Object.prototype.toString，并且没有找到 L 的 Symbol.toStringTag。
调用 ToPrimitive(m, hint Number)。
运行 OrdinaryToPrimitive(m, "number")，因为这里没有 Symbol.toPrimitive。
执行 m.valueOf()，这会获得 m 自身的值，因为它调用了默认的 Object.prototype.valueOf。
接着执行 m.toString()，这会生成 "[object Object]"，因为调用了默认的 Object.prototype.toString，并且没有找到 L 的 Symbol.toStringTag。
执行比较 "[object Object]" < "[object Object]"，结果是 false。

至于 t >= m 亦复如是，它总会输出 true。所以这里是一个漏洞——使用抽象关系比较这种方法没有意义。而利用它的方法是使编译器常数折叠，即给基准打补丁：

--- octane-box2d.js.ORIG        2016-12-16 07:28:58.442977631 +0100
+++ octane-box2d.js     2016-12-16 07:29:05.615028272 +0100
@@ -2021,8 +2021,8 @@
                     if (t == m) return true;
                     if (e.m_pairCount == e.m_pairBuffer.length) e.m_pairBuffer[e.m_pairCount] = new O;
                     var x = e.m_pairBuffer[e.m_pairCount];
-                    x.proxyA = t < m ? t : m;
-                    x.proxyB = t >= m ? t : m;
+                    x.proxyA = m;
+                    x.proxyB = t;
                     ++e.m_pairCount;
                     return true
                 },

因为这样做会跳过比较以达到 13% 的惊人的性能提升，并且所有的属性查找和内置函数的调用都会被它触发。

$ ~/Projects/v8/out/Release/d8 octane-box2d.js.ORIG
Score (Box2D): 48063
$ ~/Projects/v8/out/Release/d8 octane-box2d.js
Score (Box2D): 55359
$

那么我们是怎么做呢？事实证明，我们已经有一种用于跟踪比较对象的形状的机制，比较发生于 CompareIC，即所谓的已知接收器映射跟踪（其中的映射是 V8 的对象形状+原型），不过这是有限的抽象和严格相等比较。但是我可以很容易地扩展跟踪，并且收集反馈进行抽象的关系比较：

$ ~/Projects/v8/out/Release/d8 --trace-ic octane-box2d.js
[...SNIP...]
[CompareIC in ~+557 at octane-box2d.js:2024 ((UNINITIALIZED+UNINITIALIZED=UNINITIALIZED)->(RECEIVER+RECEIVER=KNOWN_RECEIVER))#LT @ 0x1d5a860493a1]
[CompareIC in ~+649 at octane-box2d.js:2025 ((UNINITIALIZED+UNINITIALIZED=UNINITIALIZED)->(RECEIVER+RECEIVER=KNOWN_RECEIVER))#GTE @ 0x1d5a860496e1]
[...SNIP...]
$

这里基准代码中使用的 CompareIC 告诉我们，对于我们正在查看的函数中的 LT（小于）和 GTE（大于或等于）比较，到目前为止这只能看到 RECEIVERs（接收器，V8 的 JavaScript 对象），并且所有这些接收器具有相同的映射 0x1d5a860493a1，其对应于 L 实例的映射。因此，在优化的代码中，只要我们知道比较的两侧映射的结果都为 0x1d5a860493a1，并且没人混淆 L 的原型链（即 Symbol.toPrimitive、"valueOf" 和 "toString" 这些方法都是默认的，并且没人赋予过 Symbol.toStringTag 的访问权限），我们可以将这些操作分别常量折叠为 false 和 true。剩下的故事都是关于 Crankshaft 的黑魔法，有很多一部分都是由于初始化的时候忘记正确地检查 Symbol.toStringTag 属性：

最后，性能在这个特定的基准上有了质的飞跃：

Box2D 加速

我要声明一下，当时我并不相信这个特定的行为总是指向源代码中的漏洞，所以我甚至期望外部代码经常会遇到这种情况，同时也因为我假设 JavaScript 开发人员不会总是关心这些种类的潜在错误。但是，我大错特错了，在此我马上悔改！我不得不承认，这个特殊的优化纯粹是一个基准测试的东西，并不会有助于任何真实代码（除非代码是为了从这个优化中获益而写，不过以后你可以在代码中直接写入 true 或 false，而不用再总是使用常量关系比较）。你可能想知道我们为什么在打补丁后又马上回滚了一下。这是我们整个团队投入到 ES2015 实施的非常时期，这才是真正的恶魔之舞，我们需要在没有严格的回归测试的情况下将所有新特性（ES2015 就是个怪兽）纳入传统基准。

关于 Box2D 点到为止了，让我们看看 Mandreel 基准。Mandreel 是一个用来将 C/C++ 代码编译成 JavaScript 的编译器，它并没有用上新一代的 Emscripten 编译器所使用，并且已经被弃用（或多或少已经从互联网消失了）大约三年的 JavaScript 子集 asm.js。然而，Octane 仍然有一个通过 Mandreel 编译的子弹物理引擎。MandreelLatency 测试十分有趣，它测试 Mandreel 基准与频繁的时间测量检测点。有一种说法是，由于 Mandreel 强制使用虚拟机编译器，此测试提供了由编译器引入的延迟的指示，并且测量检测点之间的长时间停顿降低了最终得分。这听起来似乎合情合理，确实有一定的意义。然而，像往常一样，供应商找到了在这个基准上作弊的方法。

Mandreel 自带一个重型初始化函数 global_init，光是解析这个函数并为其生成基线代码就花费了不可思议的时间。因为引擎通常在脚本中多次解析各种函数，一个所谓的预解析步骤用来发现脚本内的函数。然后作为函数第一次被调用完整的解析步骤以生成基线代码（或者说字节码）。这在 V8 中被称为懒解析。V8 有一些启发式检测函数，当预解析浪费时间的时候可以立刻调用，不过对于 Mandreel 基准的 global_init 函数就不太清楚了，于是我们将经历这个大家伙“预解析+解析+编译”的长时间停顿。所以我们添加了一个额外的启发式函数以避免 global_init 函数的预解析。

由此可见，在检测 global_init 和避免昂贵的预解析步骤我们几乎提升了 2 倍。我们不太确定这是否会对真实用例产生负面影响，不过保证你在预解析大函数的时候将会受益匪浅（因为它们不会立即执行）。

让我们来看看另一个稍有争议的基准测试：splay.js 测试，一个用于处理伸展树 splay tree （二叉查找树的一种）和练习自动内存管理子系统（也被称为垃圾回收器）的数据操作基准。它自带一个延迟测试，这会引导 Splay 代码通过频繁的测量检测点，检测点之间的长时间停顿表明垃圾回收器的延迟很高。此测试测量延迟暂停的频率，将它们分类到桶中，并以较低的分数惩罚频繁的长暂停。这听起来很棒！没有 GC 停顿，没有垃圾。纸上谈兵到此为止。让我们看看这个基准，以下是整个伸展树业务的核心：

这是伸展树结构的核心构造，尽管你可能想看完整的基准，不过这基本上是 SplayLatency 得分的重要来源。怎么回事？实际上，该基准测试是建立巨大的伸展树，尽可能保留所有节点，从而还原它原本的空间。使用像 V8 这样的代数垃圾回收器，如果程序违反了代数假设，会导致极端的时间停顿，从本质上看，将所有东西从新空间撤回到旧空间的开销是非常昂贵的。在旧配置中运行 V8 可以清楚地展示这个问题：

$ out/Release/d8 --trace-gc --noallocation_site_pretenuring octane-splay.js
[20872:0x7f26f24c70d0]       10 ms: Scavenge 2.7 (6.0) -> 2.7 (7.0) MB, 1.1 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]       12 ms: Scavenge 2.7 (7.0) -> 2.7 (8.0) MB, 1.7 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]       14 ms: Scavenge 3.7 (8.0) -> 3.6 (10.0) MB, 0.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]       18 ms: Scavenge 4.8 (10.5) -> 4.7 (11.0) MB, 2.5 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]       22 ms: Scavenge 5.7 (11.0) -> 5.6 (16.0) MB, 2.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]       28 ms: Scavenge 8.7 (16.0) -> 8.6 (17.0) MB, 4.3 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]       35 ms: Scavenge 9.6 (17.0) -> 9.6 (28.0) MB, 6.9 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]       49 ms: Scavenge 16.6 (28.5) -> 16.4 (29.0) MB, 8.2 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]       65 ms: Scavenge 17.5 (29.0) -> 17.5 (52.0) MB, 15.3 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]       93 ms: Scavenge 32.3 (52.5) -> 32.0 (53.5) MB, 17.6 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      126 ms: Scavenge 33.4 (53.5) -> 33.3 (68.0) MB, 31.5 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      151 ms: Scavenge 47.9 (68.0) -> 47.6 (69.5) MB, 15.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      183 ms: Scavenge 49.2 (69.5) -> 49.2 (84.0) MB, 30.9 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      210 ms: Scavenge 63.5 (84.0) -> 62.4 (85.0) MB, 14.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      241 ms: Scavenge 64.7 (85.0) -> 64.6 (99.0) MB, 28.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      268 ms: Scavenge 78.2 (99.0) -> 77.6 (101.0) MB, 16.1 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      298 ms: Scavenge 80.4 (101.0) -> 80.3 (114.5) MB, 28.2 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      324 ms: Scavenge 93.5 (114.5) -> 92.9 (117.0) MB, 16.4 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      354 ms: Scavenge 96.2 (117.0) -> 96.0 (130.0) MB, 27.6 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      383 ms: Scavenge 108.8 (130.0) -> 108.2 (133.0) MB, 16.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      413 ms: Scavenge 111.9 (133.0) -> 111.7 (145.5) MB, 27.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      440 ms: Scavenge 124.1 (145.5) -> 123.5 (149.0) MB, 17.4 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      473 ms: Scavenge 127.6 (149.0) -> 127.4 (161.0) MB, 29.5 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      502 ms: Scavenge 139.4 (161.0) -> 138.8 (165.0) MB, 18.7 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      534 ms: Scavenge 143.3 (165.0) -> 143.1 (176.5) MB, 28.5 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      561 ms: Scavenge 154.7 (176.5) -> 154.2 (181.0) MB, 19.0 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      594 ms: Scavenge 158.9 (181.0) -> 158.7 (192.0) MB, 29.2 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      622 ms: Scavenge 170.0 (192.5) -> 169.5 (197.0) MB, 19.5 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      655 ms: Scavenge 174.6 (197.0) -> 174.3 (208.0) MB, 28.7 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      683 ms: Scavenge 185.4 (208.0) -> 184.9 (212.5) MB, 19.4 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      715 ms: Scavenge 190.2 (213.0) -> 190.0 (223.5) MB, 27.7 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      743 ms: Scavenge 200.7 (223.5) -> 200.3 (228.5) MB, 19.7 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      774 ms: Scavenge 205.8 (228.5) -> 205.6 (239.0) MB, 27.1 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      802 ms: Scavenge 216.1 (239.0) -> 215.7 (244.5) MB, 19.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      833 ms: Scavenge 221.4 (244.5) -> 221.2 (254.5) MB, 26.2 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      861 ms: Scavenge 231.5 (255.0) -> 231.1 (260.5) MB, 19.9 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      892 ms: Scavenge 237.0 (260.5) -> 236.7 (270.5) MB, 26.3 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      920 ms: Scavenge 246.9 (270.5) -> 246.5 (276.0) MB, 20.1 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      951 ms: Scavenge 252.6 (276.0) -> 252.3 (286.0) MB, 25.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]      979 ms: Scavenge 262.3 (286.0) -> 261.9 (292.0) MB, 20.3 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1014 ms: Scavenge 268.2 (292.0) -> 267.9 (301.5) MB, 29.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1046 ms: Scavenge 277.7 (302.0) -> 277.3 (308.0) MB, 22.4 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1077 ms: Scavenge 283.8 (308.0) -> 283.5 (317.5) MB, 25.1 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1105 ms: Scavenge 293.1 (317.5) -> 292.7 (323.5) MB, 20.7 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1135 ms: Scavenge 299.3 (323.5) -> 299.0 (333.0) MB, 24.9 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1164 ms: Scavenge 308.6 (333.0) -> 308.1 (339.5) MB, 20.9 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1194 ms: Scavenge 314.9 (339.5) -> 314.6 (349.0) MB, 25.0 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1222 ms: Scavenge 324.0 (349.0) -> 323.6 (355.5) MB, 21.1 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1253 ms: Scavenge 330.4 (355.5) -> 330.1 (364.5) MB, 25.1 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1282 ms: Scavenge 339.4 (364.5) -> 339.0 (371.0) MB, 22.2 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1315 ms: Scavenge 346.0 (371.0) -> 345.6 (380.0) MB, 25.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1413 ms: Mark-sweep 349.9 (380.0) -> 54.2 (305.0) MB, 5.8 / 0.0 ms  (+ 87.5 ms in 73 steps since start of marking, biggest step 8.2 ms, walltime since start of marking 131 ms) finalize incremental marking via stack guard GC in old space requested
[20872:0x7f26f24c70d0]     1457 ms: Scavenge 65.8 (305.0) -> 65.1 (305.0) MB, 31.0 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1489 ms: Scavenge 69.9 (305.0) -> 69.7 (305.0) MB, 27.1 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1523 ms: Scavenge 80.9 (305.0) -> 80.4 (305.0) MB, 22.9 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1553 ms: Scavenge 85.5 (305.0) -> 85.3 (305.0) MB, 24.2 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1581 ms: Scavenge 96.3 (305.0) -> 95.7 (305.0) MB, 18.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1616 ms: Scavenge 101.1 (305.0) -> 100.9 (305.0) MB, 29.2 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1648 ms: Scavenge 111.6 (305.0) -> 111.1 (305.0) MB, 22.5 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1678 ms: Scavenge 116.7 (305.0) -> 116.5 (305.0) MB, 25.0 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1709 ms: Scavenge 127.0 (305.0) -> 126.5 (305.0) MB, 20.7 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1738 ms: Scavenge 132.3 (305.0) -> 132.1 (305.0) MB, 23.9 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1767 ms: Scavenge 142.4 (305.0) -> 141.9 (305.0) MB, 19.6 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1796 ms: Scavenge 147.9 (305.0) -> 147.7 (305.0) MB, 23.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1825 ms: Scavenge 157.8 (305.0) -> 157.3 (305.0) MB, 19.9 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1853 ms: Scavenge 163.5 (305.0) -> 163.2 (305.0) MB, 22.2 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1881 ms: Scavenge 173.2 (305.0) -> 172.7 (305.0) MB, 19.1 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1910 ms: Scavenge 179.1 (305.0) -> 178.8 (305.0) MB, 23.0 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1944 ms: Scavenge 188.6 (305.0) -> 188.1 (305.0) MB, 25.1 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     1979 ms: Scavenge 194.7 (305.0) -> 194.4 (305.0) MB, 28.4 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     2011 ms: Scavenge 204.0 (305.0) -> 203.6 (305.0) MB, 23.4 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     2041 ms: Scavenge 210.2 (305.0) -> 209.9 (305.0) MB, 23.8 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     2074 ms: Scavenge 219.4 (305.0) -> 219.0 (305.0) MB, 24.5 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     2105 ms: Scavenge 225.8 (305.0) -> 225.4 (305.0) MB, 24.7 / 0.0 ms  allocation failure
[20872:0x7f26f24c70d0]     2138 ms: Scavenge 234.8 (305.0) -> 234.4 (305.0) MB, 23.1 / 0.0 ms  allocation failure
[...SNIP...]
$

因此这里关键的发现是直接在旧空间中分配伸展树节点可基本避免在周围复制对象的所有开销，并且将次要 GC 周期的数量减少到最小（从而减少 GC 引起的停顿时间）。我们想出了一种称为分配场所预占 allocation site pretenuring 的机制，当运行到基线代码时，将尝试动态收集分配场所的反馈，以决定在此分配的对象的确切部分是否存在，如果是，则优化代码以直接在旧空间分配对象——即预占对象。

$ out/Release/d8 --trace-gc octane-splay.js
[20885:0x7ff4d7c220a0]        8 ms: Scavenge 2.7 (6.0) -> 2.6 (7.0) MB, 1.2 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]       10 ms: Scavenge 2.7 (7.0) -> 2.7 (8.0) MB, 1.6 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]       11 ms: Scavenge 3.6 (8.0) -> 3.6 (10.0) MB, 0.9 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]       17 ms: Scavenge 4.8 (10.5) -> 4.7 (11.0) MB, 2.9 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]       20 ms: Scavenge 5.6 (11.0) -> 5.6 (16.0) MB, 2.8 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]       26 ms: Scavenge 8.7 (16.0) -> 8.6 (17.0) MB, 4.5 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]       34 ms: Scavenge 9.6 (17.0) -> 9.5 (28.0) MB, 6.8 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]       48 ms: Scavenge 16.6 (28.5) -> 16.4 (29.0) MB, 8.6 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]       64 ms: Scavenge 17.5 (29.0) -> 17.5 (52.0) MB, 15.2 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]       96 ms: Scavenge 32.3 (52.5) -> 32.0 (53.5) MB, 19.6 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]      153 ms: Scavenge 61.3 (81.5) -> 57.4 (93.5) MB, 27.9 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]      432 ms: Scavenge 339.3 (364.5) -> 326.6 (364.5) MB, 12.7 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]      666 ms: Scavenge 563.7 (592.5) -> 553.3 (595.5) MB, 20.5 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]      825 ms: Mark-sweep 603.9 (644.0) -> 96.0 (528.0) MB, 4.0 / 0.0 ms  (+ 92.5 ms in 51 steps since start of marking, biggest step 4.6 ms, walltime since start of marking 160 ms) finalize incremental marking via stack guard GC in old space requested
[20885:0x7ff4d7c220a0]     1068 ms: Scavenge 374.8 (528.0) -> 362.6 (528.0) MB, 19.1 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]     1304 ms: Mark-sweep 460.1 (528.0) -> 102.5 (444.5) MB, 10.3 / 0.0 ms  (+ 117.1 ms in 59 steps since start of marking, biggest step 7.3 ms, walltime since start of marking 200 ms) finalize incremental marking via stack guard GC in old space requested
[20885:0x7ff4d7c220a0]     1587 ms: Scavenge 374.2 (444.5) -> 361.6 (444.5) MB, 13.6 / 0.0 ms  allocation failure
[20885:0x7ff4d7c220a0]     1828 ms: Mark-sweep 485.2 (520.0) -> 101.5 (519.5) MB, 3.4 / 0.0 ms  (+ 102.8 ms in 58 steps since start of marking, biggest step 4.5 ms, walltime since start of marking 183 ms) finalize incremental marking via stack guard GC in old space requested
[20885:0x7ff4d7c220a0]     2028 ms: Scavenge 371.4 (519.5) -> 358.5 (519.5) MB, 12.1 / 0.0 ms  allocation failure
[...SNIP...]
$

事实上，这完全解决了 SplayLatency 基准的问题，并提高我们的得分至超过 250%！

正如 SIGPLAN 论文中所提及的，我们有充分的理由相信，分配场所预占机制可能真的赢得了真实世界应用的欢心，并真正期待看到改进和扩展后的机制，那时将不仅仅是对象和数组字面量。但是不久后我们意识到分配场所预占机制对真实世界应用产生了相当严重的负面影响。我们实际上听到很多负面报道，包括 Ember.js 开发者和用户的唇枪舌战，虽然不仅是因为分配场所预占机制，不过它是事故的罪魁祸首。

分配场所预占机制的基本问题数之不尽，这在今天的应用中非常常见（主要是由于框架，同时还有其它原因），假设你的对象工厂最初是用于创建构成你的对象模型和视图的长周期对象的，它将你的工厂方法中的分配场所转换为永久状态，并且从工厂分配的所有内容都立即转到旧空间。现在初始设置完成后，你的应用开始工作，作为其中的一部分，从工厂分配临时对象会污染旧空间，最终导致开销昂贵的垃圾回收周期以及其它负面的副作用，例如过早触发增量标记。

我们开始重新考虑基准驱动的工作，并开始寻找现实场景驱动的替代方案，这导致了 Orinoco 的诞生，它的目标是逐步改进垃圾回收器；这个努力的一部分是一个称为“ 统一堆 unified heap ”的项目，如果页面中所有内容基本都存在，它将尝试避免复制对象。也就是说站在更高的层面看：如果新空间充满活动对象，只需将所有新空间页面标记为属于旧空间，然后从空白页面创建一个新空间。这可能不会在 SplayLatency 基准测试中得到相同的分数，但是这对于真实用例更友好，它可以自动适配具体的用例。我们还考虑并发标记 concurrent marking ，将标记工作卸载到单独的线程，从而进一步减少增量标记对延迟和吞吐量的负面影响。

轻松一刻

喘口气。

好吧，我想这足以强调我的观点了。我可以继续指出更多的例子，其中 Octane 驱动的改进后来变成了一个坏主意，也许改天我会接着写下去。但是今天就到此为止了吧。

结论

我希望现在应该清楚为什么基准测试通常是一个好主意，但是只对某个特定的级别有用，一旦你跨越了有用竞争 useful competition 的界限，你就会开始浪费你们工程师的时间，甚至开始损害到你的真实世界的性能！如果我们认真考虑 web 的性能，我们需要根据真实世界的性能来测评浏览器，而不是它们玩弄一个四年前的基准的能力。我们需要开始教育（技术）媒体，可能这没用，但至少请忽略他们。

没人害怕竞争，但是玩弄可能已经坏掉的基准不像是在合理使用工程时间。我们可以尽更大的努力，并把 JavaScript 提高到更高的水平。让我们开展有意义的性能测试，以便为最终用户和开发者带来有意思的领域竞争。此外，让我们再对运行在 Node.js（ V8 或 ChakraCore）中的服务器端和工具端代码做一些有意义的改进！

结束语：不要用传统的 JavaScript 基准来比较手机。这是真正最没用的事情，因为 JavaScript 的性能通常取决于软件，而不一定是硬件，并且 Chrome 每 6 周发布一个新版本，所以你在三月份的测试结果到了四月份就已经毫不相关了。如果为手机中的浏览器做个排名不可避免，那么至少请使用一个现代健全的浏览器基准来测试，至少这个基准要知道人们会用浏览器来干什么，比如 Speedometer 基准。

感谢你花时间阅读！

作者简介：

我是 Benedikt Meurer，住在 Ottobrunn（德国巴伐利亚州慕尼黑东南部的一个市镇）的一名软件工程师。我于 2007 年在锡根大学获得应用计算机科学与电气工程的文凭，打那以后的 5 年里我在编译器和软件分析领域担任研究员（2007 至 2008 年间还研究过微系统设计）。2013 年我加入了谷歌的慕尼黑办公室，我的工作目标主要是 V8 JavaScript 引擎，目前是 JavaScript 执行性能优化团队的一名技术领导。

via: http://benediktmeurer.de/2016/12/16/the-truth-about-traditional-javascript-benchmarks

作者：Benedikt Meurer 译者：OneNewLife 校对：OneNewLife, wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

机器学习实践指南

你可能在各种应用中听说过机器学习 machine learning （ML），比如垃圾邮件过滤、光学字符识别（OCR）和计算机视觉。

开启机器学习之旅是一个涉及多方面的漫长旅途。对于新手，有很多的书籍，有学术论文，有指导练习，有独立项目。在这些众多的选择里面，很容易迷失你最初想学习的目标。

所以在今天的文章中，我会列出 7 个步骤（和 50 多个资源）帮助你开启这个令人兴奋的计算机科学领域的大门，并逐渐成为一个机器学习高手。

请注意，这个资源列表并不详尽，只是为了让你入门。除此之外，还有更多的资源。

1、学习必要的背景知识

你可能还记得 DataCamp 网站上的学习数据科学这篇文章里面的信息图：数学和统计学是开始机器学习（ML）的关键。基础可能看起来很容易，因为它只有三个主题。但不要忘记这些实际上是三个广泛的话题。

在这里需要记住两件非常重要的事情：

首先，你一定会需要一些进一步的指导，以了解开始机器学习需要覆盖哪些知识点。
其次，这些是你进一步学习的基础。不要害怕花时间，有了这些知识你才能构建一切。

第一点很简单：学习线性代数和统计学是个好主意。这两门知识是必须要理解的。但是在你学习的同时，也应该尝试学习诸如最优化和高等微积分等主题。当你越来越深入 ML 的时候，它们就能派上用场。

如果是从零开始的，这里有一些入门指南可供参考：

Khan 学院对于初学者是非常好的资源，可以考虑学习他们的线性代数和微积分课程。
在麻省理工学院 OpenCourseWare 网站上学习线性代数课程。
Coursera course 网站上对描述统计学、概率论和推论统计学的介绍内容。

统计学是学习 ML 的关键之一

如果你更多喜欢阅读书籍，请参考以下内容：

线性代数及其应用 Linear Algebra and Its Applications
应用线性代数 Applied Linear Algebra
线性代数解决的 3000 个问题 3,000 Solved Problems in Linear Algebra
麻省理工学院在线教材

然而，在大多数情况下，你已经对统计学和数学有了一个初步的了解。很有可能你已经浏览过上面列举的的那些资源。

在这种情况下，诚实地回顾和评价你的知识是一个好主意，是否有一些领域是需要复习的，或者现在掌握的比较好的？

如果你一切都准备好了，那么现在是时候使用 R 或者 Python 应用这些知识了。作为一个通用的指导方针，选择一门语言开始是个好主意。另外，你仍然可以将另一门语言加入到你的技能池里。

为什么这些编程知识是必需的？

嗯，你会看到上面列出的课程（或你在学校或大学学习的课程）将为你提供关于数学和统计学主题的更理论性的介绍（而不是应用性的）。然而，ML 非常便于应用，你需要能够应用你所学到的所有主题。所以最好再次复习一遍之前的材料，但是这次需要付诸应用。

如果你想掌握 R 和 Python 的基础，可以看以下课程：

DataCamp 上关于 Python 或者 R 的介绍性课程： Python 语言数据科学介绍或者 R 语言编程介绍。
Edx 上关于 Python 或者 R 的介绍性课程： Python 语言数据科学介绍和 R 语言数据科学介绍。
还有很多其他免费的课程。查看 Coursera 或者 Codeacademy 了解更多。

当你打牢基础知识后，请查看 DataCamp 上的博客 Python 统计学：40+ 数据科学资源。这篇文章提供了统计学方面的 40 多个资源，这些资源都是你开始数据科学（以及 ML）需要学习的。

还要确保你查看了关于向量和数组的这篇 SciPy 教程文章，以及使用 Python 进行科学计算的研讨会。

要使用 Python 和微积分进行实践，你可以了解下 SymPy 软件包。

2、不要害怕在 ML 的“理论”上浪费时间

很多人并不会花很多精力去浏览理论材料，因为理论是枯燥的、无聊的。但从长远来看，在理论知识上投入时间是至关重要的、非常值得的。你将会更好地了解机器学习的新进展，也能和背景知识结合起来。这将有助于你保持学习积极性。

此外，理论并不会多无聊。正如你在介绍中所看到的，你可以借助非常多的资料深入学习。

书籍是吸收理论知识的最佳途径之一。它们可以让你停下来想一会儿。当然，看书是一件非常平静的事情，可能不符合你的学习风格。不过，请尝试阅读下列书籍，看看它是否适合你：

机器学习教程 Machine Learning textbook ， Tom Mitchell 著，书可能比较旧，但是却很经典。这本书很好的解释介绍了机器学习中最重要的课题，步骤详尽，逐层深入。
机器学习: 使数据有意义的算法艺术和科学 Machine Learning: The Art and Science of Algorithms that Make Sense of Data （你可以在这里看到这本书的幻灯片版本）：这本书对初学者来说非常棒。里面讨论了许多实践中的应用程序，其中有一些是在 Tom Mitchell 的书中缺少的。
机器学习之向往 Machine Learning Yearning ：这本书由吴恩达 Andrew Ng 编写的，仍未完本，但对于那些正在学习 ML 的学生来说，这一定是很好的参考资料。
算法与数据结构 Algorithms and Data Structures 由 Jurg Nievergelt 和 Klaus Hinrichs 著。
也可以参阅 Matthew North 的面向大众的数据挖掘 Data Mining for the Masses 。你会发现这本书引导你完成一些最困难的主题。
机器学习介绍 Introduction to Machine Learning 由 Alex Smola 和 S.V.N. Vishwanathan 著。

花些时间看书并研究其中涵盖的资料

视频和慕课对于喜欢边听边看来学习的人来说非常棒。慕课和视频非常的多，多到可能你都很难找到适合你的。下面列出了最知名的几个：

这个著名的机器学习慕课，是吴恩达 Andrew Ng 讲的，介绍了机器学习及其理论。别担心，这个慕课讲的非常好，一步一步深入，所以对初学者来说非常适用。
麻省理工学院 Open Courseware 的 6034 课程的节目清单，已经有点前沿了。在你开始本系列之前，你需要做一些 ML 理论方面的准备工作，但是你不会后悔的。

在这一点上，重要的是要将各种独立的技术融会贯通，形成整体的结构图。首先了解关键的概念：监督学习 supervised learning 和无监督学习 unsupervised learning 的区别、分类和回归等。手动（书面）练习可以派上用场，能帮你了解算法是如何工作的以及如何应用这些算法。在大学课程里你经常会找到一些书面练习，可以看看波特兰州立大学的 ML 课程。

3、开始动手

通过看书和看视频了解理论和算法都非常好，但是需要超越这一阶段，就要开始做一些练习。你要学着去实现这些算法，应用学到的理论。

首先，有很多介绍 Python 和 R 方面的机器学习的基础知识。当然最好的方法就是使用交互式教程：

Python 机器学习：Scikit-Learn 教程，在这篇教程里面，你可以学到使用 Scikit-Learn 构建模型的 KMeans 和支持向量机（SVM）相关的知名算法。
给初学者的 R 语言机器学习教程用 R 中的类和 caret 包介绍机器学习。
Keras 教程：Python 深度学习[25 涵盖了如何一步一步的为分类和回归任务构建多层感知器（MLP）。

还请查看以下静态的（非互动的）教程，这些需要你在 IDE 中操作：

循序渐进：Python 机器学习：一步一步地学习 Scikit-Learn。
循序渐进：使用 Keras 开发你的第一个神经网络：按这个教程一步一步地使用 Keras 开发你的第一个神经网络。
你可以考虑看更多的教程，但是机器学习精要这篇教程是非常好的。

除了教程之外，还有一些课程。参加课程可以帮助你系统性地应用学到的概念。经验丰富的导师很有帮助。以下是 Python 和机器学习的一些互动课程：

用 scikit-learn 做监督学习：学习如何构建预测模型，调整参数，并预测在未知数据上执行的效果。你将使用 Scikit-Learn 操作真实世界的数据集。
用 Python 做无监督学习：展示给你如何从未标记的数据集进行聚类、转换、可视化和提取关键信息。在课程结束时，还会构建一个推荐系统。
Python 深度学习：你将获得如何使用 Keras 2.0 进行深度学习的实践知识，Keras 2.0 是前沿的 Python 深度学习库 Keras 的最新版本。
在 Python 中应用机器学习：将学习者引入到机器学习实践中，更多地关注技术和方法，而不是这些方法背后的统计学知识。

理论学习之后，花点时间来应用你所学到的知识。

对于那些正在学习 R 语言机器学习的人，还有这些互动课程：

机器学习介绍可以让你宏观了解机器学习学科最常见的技术和应用，还可以更多地了解不同机器学习模型的评估和训练。这门课程剩下的部分重点介绍三个最基本的机器学习任务：分类、回归和聚类。
R 语言无监督学习，用 R 语言从 ML 角度提供聚类和降维的基本介绍。可以让你尽快获得数据的关键信息。
实操机器学习涵盖了构建和应用预测功能的基本组成部分，其重点是实际应用。

最后，还有很多书籍以偏向实践的方式介绍了 ML 主题。如果你想借助书籍内容和 IDE 来学习，请查看这些书籍：

Python 机器学习 Python Machine Learning Book ，Sebastian Raschka 著。
人工神经网络与深度学习导论：Python 应用实用指南 Introduction to Artificial Neural Networks and Deep Learning: A Practical Guide with Applications in Python ，Sebastian Raschka 著。
R 语言机器学习 Machine Learning with R ，Brett Lantz 著。

4、练习

实践比使用 Python 进行练习和修改材料更重要。这一步对我来说可能是最难的。在做了一些练习后看看其他人是如何实现 ML 算法的。然后，开始你自己的项目，阐述你对 ML 算法和理论的理解。

最直接的方法之一就是将练习的规模做得更大些。要做一个更大的练习，就需要你做更多的数据清理和功能工程。

从 Kaggle 开始。如果你需要额外的帮助来征服所谓的“数据恐惧”，请查看 Kaggle 的 Python 机器学习教程和 Kaggle 的 R 语言机器学习教程。这些将带给您快速的提升。
此后，你也可以自己开始挑战。查看这些网站，您可以在其中找到大量的 ML 数据集：UCI 机器学习仓库，用于机器学习的公开数据集和 data.world。

熟能生巧。

5、项目

虽然做一些小的练习也不错，但是在最后，您需要做一个项目，可以在其中展示您对使用到的 ML 算法的理解。

最好的练习是实现你自己的 ML 算法。您可以在以下页面中阅读更多关于为什么您应该做这样的练习，以及您可以从中学到什么内容：

接下来，您可以查看以下文章和仓库。可以从中获得一些灵感，并且了解他们是如何实现 ML 算法的。

开始时项目可能会很难，但是可以极大增加你的理解。

6、不要停止

对 ML 的学习永远不能停止，即使你在这个领域工作了十年，总是有新的东西要学习，许多人都将会证实这一点。

例如，ML 趋势，比如深度学习 deep learning 现在就很受欢迎。你也可以专注于那些现在不怎么火，但是将来会火的话题上。如果你想了解更多，可以看看这个有趣的问题和答案。

当你苦恼于掌握基础知识时，你最先想到的可能不是论文。但是它们是你紧跟最新研究的一个途径。论文并不适合刚刚开始学习的人，但是绝对适合高级人员。

其他技术也是需要考虑的。但是当你刚开始学习时，不要担心这些。例如，您可以专注于 Python 或 R 语言（取决于你已经知道哪一个），并把它到你的技能池里。你可以通过这篇文章来查找一些感兴趣的资源。

如果您还想转向大数据，您可以考虑研究 Spark。这里有一些有趣的资源：

其他编程语言，比如 Java、JavaScript、C 和 C++ 在 ML 中越来越重要。从长远来看，您可以考虑将其中一种语言添加到学习列表中。你可以使用这些博客文章来指导你选择：

学无止境。

7、利用一切可以利用的资源

机器学习是一个充满难度的话题，有时候可能会让你失去动力。或者也许你觉得你需要点改变。在这种情况下，请记住，有很多资源可以让你打消掉这种想法。查看以下资源：

播客是可以让你继续你的 ML 旅程，紧跟这个领域最新的发展的伟大资源：

当然，还有更多的播客。

文档和软件包源代码是深入了解 ML 算法的实现的两种方法。查看这些仓库：

Scikit-Learn：知名的 Python ML 软件包
Keras： Python 深度学习软件包
caret：非常受欢迎的用于分类和回归训练 R 软件包

可视化是深入 ML 理论的最新也是最流行的方式之一。它们对初学者来说非常棒，但对于更高级的学习者来说也是非常有趣的。你肯定会被下面这些可视化资源所吸引，它们能让你更加了解 ML 的工作原理：

机器学习的可视化介绍
Distill 使 ML 研究清晰，动态和生动。
如果你想玩下神经网络架构，可以看下 Tensorflow - 神经网络游乐场。
更多的看这里：机器学习算法最佳的可视化方法是什么？

学习中的一些变化更加能激励你。

现在你可以开始了

现在一切都取决于你自己了。学习机器学习是一个持续的过程，所以开始的越早就会越好。运用你手边的一切工具开始吧。祝你好运，并确保让我们知道你的进步。

这篇文章是我基于 Quora 问题（小白该如何开始机器学习）给出的答案。

作者简介：

Karlijn Willems，数据科学记者

via: https://medium.freecodecamp.org/how-machines-learn-a-practical-guide-203aae23cafb

作者：Karlijn Willems 译者：Flowsnow 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

常用 GDB 命令中文速览

Fsf 发布于 2017-09-24
另请参阅: 软件开发,调试, gdb
1 条评论

break -- 在指定的行或函数处设置断点，缩写为 b
info breakpoints -- 打印未删除的所有断点，观察点和捕获点的列表，缩写为 i b
disable -- 禁用断点，缩写为 dis
enable -- 启用断点
clear -- 清除指定行或函数处的断点
delete -- 删除断点，缩写为 d
tbreak -- 设置临时断点，参数同 break，但在程序第一次停住后会被自动删除
watch -- 为表达式（或变量）设置观察点，当表达式（或变量）的值有变化时，暂停程序执行
step -- 单步跟踪，如果有函数调用，会进入该函数，缩写为 s
reverse-step -- 反向单步跟踪，如果有函数调用，会进入该函数
next -- 单步跟踪，如果有函数调用，不会进入该函数，缩写为 n
reverse-next -- 反向单步跟踪，如果有函数调用，不会进入该函数
return -- 使选定的栈帧返回到其调用者
finish -- 执行直到选择的栈帧返回，缩写为 fin
until -- 执行直到达到当前栈帧中当前行后的某一行（用于跳过循环、递归函数调用），缩写为 u
continue -- 恢复程序执行，缩写为 c
print -- 打印表达式 EXP 的值，缩写为 p
x -- 查看内存
display -- 每次程序停止时打印表达式 EXP 的值（自动显示）
info display -- 打印早先设置为自动显示的表达式列表
disable display -- 禁用自动显示
enable display -- 启用自动显示
undisplay -- 删除自动显示项
help -- 打印命令列表（带参数时查找命令的帮助），缩写为 h
attach -- 挂接到已在运行的进程来调试
run -- 启动被调试的程序，缩写为 r
backtrace -- 查看程序调用栈的信息，缩写为 bt
ptype -- 打印类型 TYPE 的定义

break

使用 break 命令（缩写 b）来设置断点。

用法：

break 当不带参数时，在所选栈帧中执行的下一条指令处设置断点。
break <function-name> 在函数体入口处打断点，在 C++ 中可以使用 class::function 或 function(type, ...) 格式来指定函数名。
break <line-number> 在当前源码文件指定行的开始处打断点。
break -N break +N 在当前源码行前面或后面的 N 行开始处打断点，N 为正整数。
break <filename:linenum> 在源码文件 filename 的 linenum 行处打断点。
break <filename:function> 在源码文件 filename 的 function 函数入口处打断点。
break <address> 在程序指令的地址处打断点。
break ... if <cond> 设置条件断点，... 代表上述参数之一（或无参数），cond 为条件表达式，仅在 cond 值非零时暂停程序执行。

详见官方文档。

info breakpoints

查看断点，观察点和捕获点的列表。

用法：

info breakpoints [list...]
info break [list...]
list... 用来指定若干个断点的编号（可省略），可以是 2， 1-3， 2 5 等。

disable

禁用一些断点。参数是用空格分隔的断点编号。要禁用所有断点，不加参数。

禁用的断点不会被忘记，但直到重新启用才有效。

用法：

disable [breakpoints] [list...]
breakpoints 是 disable 的子命令（可省略），list... 同 info breakpoints 中的描述。

详见官方文档。

enable

启用一些断点。给出断点编号（以空格分隔）作为参数。没有参数时，所有断点被启用。

用法：

enable [breakpoints] [list...] 启用指定的断点（或所有定义的断点）。
enable [breakpoints] once list... 临时启用指定的断点。GDB 在停止您的程序后立即禁用这些断点。
enable [breakpoints] delete list... 使指定的断点启用一次，然后删除。一旦您的程序停止，GDB 就会删除这些断点。等效于用 tbreak 设置的断点。

breakpoints 同 disable 中的描述。

详见官方文档。

clear

在指定行或函数处清除断点。参数可以是行号，函数名称或 * 跟一个地址。

用法：

clear 当不带参数时，清除所选栈帧在执行的源码行中的所有断点。
clear <function>, clear <filename:function> 删除在命名函数的入口处设置的任何断点。
clear <linenum>, clear <filename:linenum> 删除在指定的文件指定的行号的代码中设置的任何断点。
clear <address> 清除指定程序指令的地址处的断点。

详见官方文档。

delete

删除一些断点或自动显示表达式。参数是用空格分隔的断点编号。要删除所有断点，不加参数。

用法： delete [breakpoints] [list...]

详见官方文档。

tbreak

设置临时断点。参数形式同 break 一样。

除了断点是临时的之外，其他同 break 一样，所以在命中时会被删除。

详见官方文档。

watch

为表达式设置观察点。

用法： watch [-l|-location] <expr> 每当一个表达式的值改变时，观察点就会暂停程序执行。

如果给出了 -l 或者 -location，则它会对 expr 求值并观察它所指向的内存。例如，watch *(int *)0x12345678 将在指定的地址处观察一个 4 字节的区域（假设 int 占用 4 个字节）。

详见官方文档。

step

单步执行程序，直到到达不同的源码行。

用法： step [N] 参数 N 表示执行 N 次（或由于另一个原因直到程序停止）。

警告：如果当控制在没有调试信息的情况下编译的函数中使用 step 命令，则执行将继续进行，直到控制到达具有调试信息的函数。同样，它不会进入没有调试信息编译的函数。

要执行没有调试信息的函数，请使用 stepi 命令，详见后文。

详见官方文档。

reverse-step

反向单步执行程序，直到到达另一个源码行的开头。

用法： reverse-step [N] 参数 N 表示执行 N 次（或由于另一个原因直到程序停止）。

详见官方文档。

单步执行程序，执行完子程序调用。

用法： next [N]

与 step 不同，如果当前的源代码行调用子程序，则此命令不会进入子程序，而是将其视为单个源代码行，继续执行。

详见官方文档。

reverse-next

反向步进程序，执行完子程序调用。

用法： reverse-next [N]

如果要执行的源代码行调用子程序，则此命令不会进入子程序，调用被视为一个指令。

参数 N 表示执行 N 次（或由于另一个原因直到程序停止）。

详见官方文档。

return

您可以使用 return 命令取消函数调用的执行。如果你给出一个表达式参数，它的值被用作函数的返回值。

用法： return <expression> 将 expression 的值作为函数的返回值并使函数直接返回。

详见官方文档。

finish

执行直到选定的栈帧返回。

用法： finish 返回后，返回的值将被打印并放入到值历史记录中。

详见官方文档。

until

执行直到程序到达当前栈帧中当前行之后（与 break 命令相同的参数）的源码行。此命令用于通过一个多次的循环，以避免单步执行。

用法：until <location> 或 u <location> 继续运行程序，直到达到指定的位置，或者当前栈帧返回。

详见官方文档。

continue

在信号或断点之后，继续运行被调试的程序。

用法： continue [N] 如果从断点开始，可以使用数字 N 作为参数，这意味着将该断点的忽略计数设置为 N - 1(以便断点在第 N 次到达之前不会中断)。如果启用了非停止模式（使用 show non-stop 查看），则仅继续当前线程，否则程序中的所有线程都将继续。

详见官方文档。

print

求值并打印表达式 EXP 的值。可访问的变量是所选栈帧的词法环境，以及范围为全局或整个文件的所有变量。

用法：

print [expr] 或 print /f [expr] expr 是一个（在源代码语言中的）表达式。

默认情况下，expr 的值以适合其数据类型的格式打印；您可以通过指定 /f 来选择不同的格式，其中 f 是一个指定格式的字母；详见输出格式。

如果省略 expr，GDB 再次显示最后一个值。

要以每行一个成员带缩进的格式打印结构体变量请使用命令 set print pretty on，取消则使用命令 set print pretty off。

可使用命令 show print 查看所有打印的设置。

详见官方文档。

x

检查内存。

用法： x/nfu <addr> 或 x <addr> n、f 和 u 都是可选参数，用于指定要显示的内存以及如何格式化。addr 是要开始显示内存的地址的表达式。

n 重复次数（默认值是 1），指定要显示多少个单位（由 u 指定）的内存值。

f 显示格式（初始默认值是 x），显示格式是 print('x'，'d'，'u'，'o'，'t'，'a'，'c'，'f'，'s') 使用的格式之一，再加 i（机器指令）。

u 单位大小，b 表示单字节，h 表示双字节，w 表示四字节，g 表示八字节。

例如：

x/3uh 0x54320 表示从地址 0x54320 开始以无符号十进制整数的格式，双字节为单位来显示 3 个内存值。

x/16xb 0x7f95b7d18870 表示从地址 0x7f95b7d18870 开始以十六进制整数的格式，单字节为单位显示 16 个内存值。

详见官方文档。

display

每次程序暂停时，打印表达式 EXP 的值。

用法： display <expr>, display/fmt <expr> 或 display/fmt <addr> fmt 用于指定显示格式。像 print 命令里的 /f 一样。

对于格式 i 或 s，或者包括单位大小或单位数量，将表达式 addr 添加为每次程序停止时要检查的内存地址。

详见官方文档。

info display

打印自动显示的表达式列表，每个表达式都带有项目编号，但不显示其值。

包括被禁用的表达式和不能立即显示的表达式（当前不可用的自动变量）。

undisplay

取消某些表达式在程序暂停时的自动显示。参数是表达式的编号（使用 info display 查询编号）。不带参数表示取消所有自动显示表达式。

delete display 具有与此命令相同的效果。

disable display

禁用某些表达式在程序暂停时的自动显示。禁用的显示项目不会被自动打印，但不会被忘记。它可能稍后再次被启用。

参数是表达式的编号（使用 info display 查询编号）。不带参数表示禁用所有自动显示表达式。

enable display

启用某些表达式在程序暂停时的自动显示。

参数是重新显示的表达式的编号（使用 info display 查询编号）。不带参数表示启用所有自动显示表达式。

help

打印命令列表。

您可以使用不带参数的 help（缩写为 h）来显示命令的类别名的简短列表。

使用 help <class> 您可以获取该类中的各个命令的列表。使用 help <command> 显示如何使用该命令。

详见官方文档。

attach

挂接到 GDB 之外的进程或文件。该命令可以将进程 ID 或设备文件作为参数。

对于进程 ID，您必须具有向进程发送信号的权限，并且必须具有与调试器相同的有效的 uid。

用法： attach <process-id> GDB 在安排调试指定的进程之后做的第一件事是暂停该进程。

无论是通过 attach 命令挂接的进程还是通过 run 命令启动的进程，您都可以使用的 GDB 命令来检查和修改挂接的进程。

详见官方文档。

run

启动被调试的程序。

可以直接指定参数，也可以用 set args 设置（启动所需的）参数。

例如： run arg1 arg2 ... 等效于

set args arg1 arg2 ...
run

还允许使用 >、 < 或 >> 进行输入和输出重定向。

详见官方文档。

backtrace

打印整体栈帧信息。

bt 打印整体栈帧信息，每个栈帧一行。
bt n 类似于上，但只打印最内层的 n 个栈帧。
bt -n 类似于上，但只打印最外层的 n 个栈帧。
bt full n 类似于 bt n，还打印局部变量的值。

where 和 info stack(缩写 info s) 是 backtrace 的别名。调用栈信息类似如下：

(gdb) where
#0  vconn_stream_run (vconn=0x99e5e38) at lib/vconn-stream.c:232
#1  0x080ed68a in vconn_run (vconn=0x99e5e38) at lib/vconn.c:276
#2  0x080dc6c8 in rconn_run (rc=0x99dbbe0) at lib/rconn.c:513
#3  0x08077b83 in ofconn_run (ofconn=0x99e8070, handle_openflow=0x805e274 <handle_openflow>) at ofproto/connmgr.c:1234
#4  0x08075f92 in connmgr_run (mgr=0x99dc878, handle_openflow=0x805e274 <handle_openflow>) at ofproto/connmgr.c:286
#5  0x08057d58 in ofproto_run (p=0x99d9ba0) at ofproto/ofproto.c:1159
#6  0x0804f96b in bridge_run () at vswitchd/bridge.c:2248
#7  0x08054168 in main (argc=4, argv=0xbf8333e4) at vswitchd/ovs-vswitchd.c:125

详见官方文档。

ptype

打印类型 TYPE 的定义。

用法： ptype[/FLAGS] TYPE-NAME | EXPRESSION

参数可以是由 typedef 定义的类型名，或者 struct STRUCT-TAG 或者 class CLASS-NAME 或者 union UNION-TAG 或者 enum ENUM-TAG。

根据所选的栈帧的词法上下文来查找该名字。

类似的命令是 whatis，区别在于 whatis 不展开由 typedef 定义的数据类型，而 ptype 会展开，举例如下：

/* 类型声明与变量定义 */
typedef double real_t;
struct complex {
    real_t real;
    double imag;
};
typedef struct complex complex_t;

complex_t var;
real_t *real_pointer_var;

这两个命令给出了如下输出：

(gdb) whatis var
type = complex_t
(gdb) ptype var
type = struct complex {
    real_t real;
    double imag;
}
(gdb) whatis complex_t
type = struct complex
(gdb) whatis struct complex
type = struct complex
(gdb) ptype struct complex
type = struct complex {
    real_t real;
    double imag;
}
(gdb) whatis real_pointer_var
type = real_t *
(gdb) ptype real_pointer_var
type = double *

详见官方文档。

参考资料

Debugging with GDB

译者：robot527 校对：mudongliang， wxy

开发一个 Linux 调试器（七）：源码级断点

Simon Brand 发布于 2017-09-22
另请参阅: 软件开发,调试器
评论

在内存地址上设置断点虽然不错，但它并没有提供最方便用户的工具。我们希望能够在源代码行和函数入口地址上设置断点，以便我们可以在与代码相同的抽象级别中进行调试。

这篇文章将会添加源码级断点到我们的调试器中。通过所有我们已经支持的功能，这要比起最初听起来容易得多。我们还将添加一个命令来获取符号的类型和地址，这对于定位代码或数据以及理解链接概念非常有用。

系列索引

随着后面文章的发布，这些链接会逐渐生效。

断点

DWARF

Elves 和 dwarves 这篇文章，描述了 DWARF 调试信息是如何工作的，以及如何用它来将机器码映射到高层源码中。回想一下，DWARF 包含了函数的地址范围和一个允许你在抽象层之间转换代码位置的行表。我们将使用这些功能来实现我们的断点。

函数入口

如果你考虑重载、成员函数等等，那么在函数名上设置断点可能有点复杂，但是我们将遍历所有的编译单元，并搜索与我们正在寻找的名称匹配的函数。DWARF 信息如下所示：

< 0><0x0000000b>  DW_TAG_compile_unit
                    DW_AT_producer              clang version 3.9.1 (tags/RELEASE_391/final)
                    DW_AT_language              DW_LANG_C_plus_plus
                    DW_AT_name                  /super/secret/path/MiniDbg/examples/variable.cpp
                    DW_AT_stmt_list             0x00000000
                    DW_AT_comp_dir              /super/secret/path/MiniDbg/build
                    DW_AT_low_pc                0x00400670
                    DW_AT_high_pc               0x0040069c

LOCAL_SYMBOLS:
< 1><0x0000002e>    DW_TAG_subprogram
                      DW_AT_low_pc                0x00400670
                      DW_AT_high_pc               0x0040069c
                      DW_AT_name                  foo
                      ...
...
<14><0x000000b0>    DW_TAG_subprogram
                      DW_AT_low_pc                0x00400700
                      DW_AT_high_pc               0x004007a0
                      DW_AT_name                  bar
                      ...

我们想要匹配 DW_AT_name 并使用 DW_AT_low_pc（函数的起始地址）来设置我们的断点。

void debugger::set_breakpoint_at_function(const std::string& name) {
    for (const auto& cu : m_dwarf.compilation_units()) {
        for (const auto& die : cu.root()) {
            if (die.has(dwarf::DW_AT::name) && at_name(die) == name) {
                auto low_pc = at_low_pc(die);
                auto entry = get_line_entry_from_pc(low_pc);
                ++entry; //skip prologue
                set_breakpoint_at_address(entry->address);
            }
        }
    }
}

这代码看起来有点奇怪的唯一一点是 ++entry。问题是函数的 DW_AT_low_pc 不指向该函数的用户代码的起始地址，它指向 prologue 的开始。编译器通常会输出一个函数的 prologue 和 epilogue，它们用于执行保存和恢复堆栈、操作堆栈指针等。这对我们来说不是很有用，所以我们将入口行加一来获取用户代码的第一行而不是 prologue。DWARF 行表实际上具有一些功能，用于将入口标记为函数 prologue 之后的第一行，但并不是所有编译器都输出它，因此我采用了原始的方法。

源码行

要在高层源码行上设置一个断点，我们要将这个行号转换成 DWARF 中的一个地址。我们将遍历编译单元，寻找一个名称与给定文件匹配的编译单元，然后查找与给定行对应的入口。

DWARF 看上去有点像这样：

.debug_line: line number info for a single cu
Source lines (from CU-DIE at .debug_info offset 0x0000000b):

NS new statement, BB new basic block, ET end of text sequence
PE prologue end, EB epilogue begin
IS=val ISA number, DI=val discriminator value
<pc>        [lno,col] NS BB ET PE EB IS= DI= uri: "filepath"
0x004004a7  [   1, 0] NS uri: "/super/secret/path/a.hpp"
0x004004ab  [   2, 0] NS
0x004004b2  [   3, 0] NS
0x004004b9  [   4, 0] NS
0x004004c1  [   5, 0] NS
0x004004c3  [   1, 0] NS uri: "/super/secret/path/b.hpp"
0x004004c7  [   2, 0] NS
0x004004ce  [   3, 0] NS
0x004004d5  [   4, 0] NS
0x004004dd  [   5, 0] NS
0x004004df  [   4, 0] NS uri: "/super/secret/path/ab.cpp"
0x004004e3  [   5, 0] NS
0x004004e8  [   6, 0] NS
0x004004ed  [   7, 0] NS
0x004004f4  [   7, 0] NS ET

所以如果我们想要在 ab.cpp 的第五行设置一个断点，我们将查找与行 (0x004004e3) 相关的入口并设置一个断点。

void debugger::set_breakpoint_at_source_line(const std::string& file, unsigned line) {
    for (const auto& cu : m_dwarf.compilation_units()) {
        if (is_suffix(file, at_name(cu.root()))) {
            const auto& lt = cu.get_line_table();

            for (const auto& entry : lt) {
                if (entry.is_stmt && entry.line == line) {
                    set_breakpoint_at_address(entry.address);
                    return;
                }
            }
        }
    }
}

我这里做了 is_suffix hack，这样你可以输入 c.cpp 代表 a/b/c.cpp 。当然你实际上应该使用大小写敏感路径处理库或者其它东西，但是我比较懒。entry.is_stmt 是检查行表入口是否被标记为一个语句的开头，这是由编译器根据它认为是断点的最佳目标的地址设置的。

符号查找

当我们在对象文件层时，符号是王者。函数用符号命名，全局变量用符号命名，你得到一个符号，我们得到一个符号，每个人都得到一个符号。在给定的对象文件中，一些符号可能引用其他对象文件或共享库，链接器将从符号引用创建一个可执行程序。

可以在正确命名的符号表中查找符号，它存储在二进制文件的 ELF 部分中。幸运的是，libelfin 有一个不错的接口来做这件事，所以我们不需要自己处理所有的 ELF 的事情。为了让你知道我们在处理什么，下面是一个二进制文件的 .symtab 部分的转储，它由 readelf 生成：

Num:    Value          Size Type    Bind   Vis      Ndx Name
 0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
 1: 0000000000400238     0 SECTION LOCAL  DEFAULT    1
 2: 0000000000400254     0 SECTION LOCAL  DEFAULT    2
 3: 0000000000400278     0 SECTION LOCAL  DEFAULT    3
 4: 00000000004002c8     0 SECTION LOCAL  DEFAULT    4
 5: 0000000000400430     0 SECTION LOCAL  DEFAULT    5
 6: 00000000004004e4     0 SECTION LOCAL  DEFAULT    6
 7: 0000000000400508     0 SECTION LOCAL  DEFAULT    7
 8: 0000000000400528     0 SECTION LOCAL  DEFAULT    8
 9: 0000000000400558     0 SECTION LOCAL  DEFAULT    9
10: 0000000000400570     0 SECTION LOCAL  DEFAULT   10
11: 0000000000400714     0 SECTION LOCAL  DEFAULT   11
12: 0000000000400720     0 SECTION LOCAL  DEFAULT   12
13: 0000000000400724     0 SECTION LOCAL  DEFAULT   13
14: 0000000000400750     0 SECTION LOCAL  DEFAULT   14
15: 0000000000600e18     0 SECTION LOCAL  DEFAULT   15
16: 0000000000600e20     0 SECTION LOCAL  DEFAULT   16
17: 0000000000600e28     0 SECTION LOCAL  DEFAULT   17
18: 0000000000600e30     0 SECTION LOCAL  DEFAULT   18
19: 0000000000600ff0     0 SECTION LOCAL  DEFAULT   19
20: 0000000000601000     0 SECTION LOCAL  DEFAULT   20
21: 0000000000601018     0 SECTION LOCAL  DEFAULT   21
22: 0000000000601028     0 SECTION LOCAL  DEFAULT   22
23: 0000000000000000     0 SECTION LOCAL  DEFAULT   23
24: 0000000000000000     0 SECTION LOCAL  DEFAULT   24
25: 0000000000000000     0 SECTION LOCAL  DEFAULT   25
26: 0000000000000000     0 SECTION LOCAL  DEFAULT   26
27: 0000000000000000     0 SECTION LOCAL  DEFAULT   27
28: 0000000000000000     0 SECTION LOCAL  DEFAULT   28
29: 0000000000000000     0 SECTION LOCAL  DEFAULT   29
30: 0000000000000000     0 SECTION LOCAL  DEFAULT   30
31: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS init.c
32: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
33: 0000000000600e28     0 OBJECT  LOCAL  DEFAULT   17 __JCR_LIST__
34: 00000000004005a0     0 FUNC    LOCAL  DEFAULT   10 deregister_tm_clones
35: 00000000004005e0     0 FUNC    LOCAL  DEFAULT   10 register_tm_clones
36: 0000000000400620     0 FUNC    LOCAL  DEFAULT   10 __do_global_dtors_aux
37: 0000000000601028     1 OBJECT  LOCAL  DEFAULT   22 completed.6917
38: 0000000000600e20     0 OBJECT  LOCAL  DEFAULT   16 __do_global_dtors_aux_fin
39: 0000000000400640     0 FUNC    LOCAL  DEFAULT   10 frame_dummy
40: 0000000000600e18     0 OBJECT  LOCAL  DEFAULT   15 __frame_dummy_init_array_
41: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS /super/secret/path/MiniDbg/
42: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
43: 0000000000400818     0 OBJECT  LOCAL  DEFAULT   14 __FRAME_END__
44: 0000000000600e28     0 OBJECT  LOCAL  DEFAULT   17 __JCR_END__
45: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS
46: 0000000000400724     0 NOTYPE  LOCAL  DEFAULT   13 __GNU_EH_FRAME_HDR
47: 0000000000601000     0 OBJECT  LOCAL  DEFAULT   20 _GLOBAL_OFFSET_TABLE_
48: 0000000000601028     0 OBJECT  LOCAL  DEFAULT   21 __TMC_END__
49: 0000000000601020     0 OBJECT  LOCAL  DEFAULT   21 __dso_handle
50: 0000000000600e20     0 NOTYPE  LOCAL  DEFAULT   15 __init_array_end
51: 0000000000600e18     0 NOTYPE  LOCAL  DEFAULT   15 __init_array_start
52: 0000000000600e30     0 OBJECT  LOCAL  DEFAULT   18 _DYNAMIC
53: 0000000000601018     0 NOTYPE  WEAK   DEFAULT   21 data_start
54: 0000000000400710     2 FUNC    GLOBAL DEFAULT   10 __libc_csu_fini
55: 0000000000400570    43 FUNC    GLOBAL DEFAULT   10 _start
56: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
57: 0000000000400714     0 FUNC    GLOBAL DEFAULT   11 _fini
58: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@@GLIBC_
59: 0000000000400720     4 OBJECT  GLOBAL DEFAULT   12 _IO_stdin_used
60: 0000000000601018     0 NOTYPE  GLOBAL DEFAULT   21 __data_start
61: 00000000004006a0   101 FUNC    GLOBAL DEFAULT   10 __libc_csu_init
62: 0000000000601028     0 NOTYPE  GLOBAL DEFAULT   22 __bss_start
63: 0000000000601030     0 NOTYPE  GLOBAL DEFAULT   22 _end
64: 0000000000601028     0 NOTYPE  GLOBAL DEFAULT   21 _edata
65: 0000000000400670    44 FUNC    GLOBAL DEFAULT   10 main
66: 0000000000400558     0 FUNC    GLOBAL DEFAULT    9 _init

你可以在对象文件中看到用于设置环境的很多符号，最后还可以看到 main 符号。

我们对符号的类型、名称和值（地址）感兴趣。我们有一个该类型的 symbol_type 枚举，并使用一个 std::string 作为名称，std::uintptr_t 作为地址：

enum class symbol_type {
    notype,            // No type (e.g., absolute symbol)
    object,            // Data object
    func,              // Function entry point
    section,           // Symbol is associated with a section
    file,              // Source file associated with the
};                     // object file

std::string to_string (symbol_type st) {
    switch (st) {
    case symbol_type::notype: return "notype";
    case symbol_type::object: return "object";
    case symbol_type::func: return "func";
    case symbol_type::section: return "section";
    case symbol_type::file: return "file";
    }
}

struct symbol {
    symbol_type type;
    std::string name;
    std::uintptr_t addr;
};

我们需要将从 libelfin 获得的符号类型映射到我们的枚举，因为我们不希望依赖关系破环这个接口。幸运的是，我为所有的东西选了同样的名字，所以这样很简单：

symbol_type to_symbol_type(elf::stt sym) {
    switch (sym) {
    case elf::stt::notype: return symbol_type::notype;
    case elf::stt::object: return symbol_type::object;
    case elf::stt::func: return symbol_type::func;
    case elf::stt::section: return symbol_type::section;
    case elf::stt::file: return symbol_type::file;
    default: return symbol_type::notype;
    }
};

最后我们要查找符号。为了说明的目的，我循环查找符号表的 ELF 部分，然后收集我在其中找到的任意符号到 std::vector 中。更智能的实现可以建立从名称到符号的映射，这样你只需要查看一次数据就行了。

std::vector<symbol> debugger::lookup_symbol(const std::string& name) {
    std::vector<symbol> syms;

    for (auto &sec : m_elf.sections()) {
        if (sec.get_hdr().type != elf::sht::symtab && sec.get_hdr().type != elf::sht::dynsym)
            continue;

        for (auto sym : sec.as_symtab()) {
            if (sym.get_name() == name) {
                auto &d = sym.get_data();
                syms.push_back(symbol{to_symbol_type(d.type()), sym.get_name(), d.value});
            }
        }
    }

    return syms;
}

添加命令

一如往常，我们需要添加一些更多的命令来向用户暴露功能。对于断点，我使用 GDB 风格的接口，其中断点类型是通过你传递的参数推断的，而不用要求显式切换：

0x<hexadecimal> -> 断点地址
<line>:<filename> -> 断点行号
<anything else> -> 断点函数名

    else if(is_prefix(command, "break")) {
        if (args[1][0] == '0' && args[1][1] == 'x') {
            std::string addr {args[1], 2};
            set_breakpoint_at_address(std::stol(addr, 0, 16));
        }
        else if (args[1].find(':') != std::string::npos) {
            auto file_and_line = split(args[1], ':');
            set_breakpoint_at_source_line(file_and_line[0], std::stoi(file_and_line[1]));
        }
        else {
            set_breakpoint_at_function(args[1]);
        }
    }

对于符号，我们将查找符号并打印出我们发现的任何匹配项：

else if(is_prefix(command, "symbol")) {
    auto syms = lookup_symbol(args[1]);
    for (auto&& s : syms) {
        std::cout << s.name << ' ' << to_string(s.type) << " 0x" << std::hex << s.addr << std::endl;
    }
}

测试一下

在一个简单的二进制文件上启动调试器，并设置源代码级别的断点。在一些 foo 函数上设置一个断点，看到我的调试器停在它上面是我这个项目最有价值的时刻之一。

符号查找可以通过在程序中添加一些函数或全局变量并查找它们的名称来进行测试。请注意，如果你正在编译 C++ 代码，你还需要考虑名称重整。

本文就这些了。下一次我将展示如何向调试器添加堆栈展开支持。

你可以在这里找到这篇文章的代码。

via: https://blog.tartanllama.xyz/c++/2017/06/19/writing-a-linux-debugger-source-break/

作者：Simon Brand 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出