Archive

Archive for April, 2013

Open Projects in IonMonkey

April 21st, 2013 No comments

昨天 Mozilla 的 Nicolas B. Pierron 在邮件列表中给出了几个 IonMonkey 的开放项目,有兴趣的同学可以去 SpiderMonkey 的邮件列表看看。这里列出项目的简介:

  • Clarifying our heuristics, to be able to make guesses while we are compiling in IonMonkey, and recompile without the guarded assumptions if the bailout paths are too costly. Our current view is mostly black & white and only one bad use case can destroy the performances. 
  • Adding resume operations, such as an instruction can be moved to a later point in the control flow. This optimization is a blocker for any optimization which can be done with the escape analysis.
  • Adding profile guided optimization, the idea would be to profile which branches are used and to prune branches which are unused, either while generating the MIR Graph, or as a second optimization phase working on the graph. 
  • Improving our Alias Analysis to take advantage of the type set (this might help a lot kraken benchmarks, by factoring out array accesses).
  • Improve dummy functions used for asm.js boundaries. Asm.js needs to communicate with the DOM, and to do so it need some trampoline functions which are used as an interface with the DOM API. Such trampolines might transform typed arrays into strings or objects and serialize the result back into typed arrays.

[GSoC] Google Summer of Code 2013

April 20th, 2013 No comments

一年一度的 GSoC 又开始了。

今年共有 177 个开源组织进入 GSoC 组织者名单,与编译器相关的组织有:

  • Mozilla:包含 SpiderMonkey JavaScript 引擎。不过今年 SpiderMonkey 团队没有提交自己的 Idea,不一定有 mentor。
  • Chromium:Chrome 背后的开源项目。包含 V8 引擎。Idea 页面的内容很少,需要自己提交。
  • LLVM:Clang/LLVM 项目,不用介绍了。
  • GCC:GNU GCC 项目,不用介绍了。
  • PLASMA @ UMASS:一个大学实验室的项目,里面有一个叫做 Doppio 的 JVM 项目,完全用 CoffeeScript 实现,比较有意思。
  • CERN SFT:欧洲原子能机构下属的软件团体。他们基于 Clang/LLVM 搭建了一个 C++ 的交互式环境 Cling。目前需要对这个环境进行一些补充。

很遗憾今年 Jikes RVM 没有被选中。前几年入围的 Jato VM 这次也没有入围。

除了那些老牌的开源组织(Linux、GNU、Apache、*BSD)之外,还出现了很多做生物科技、计算生物学和计算医疗的开源组织。他们的项目多半是为了自己的网站进行重新部署,或者是为自己编写新的 Android/iPhone/HTML5 应用,并不需要专业的生物学知识。

另外注意到还有几个自由团体、标准制定组织和大学成功的进入了 GSoC。大学的实验室作为开源组织进入 GSoC 有点奇怪,感觉必然是本大学的学生能够成功申请到的概率要大很多,毕竟能够直接面对面的交流 Idea 的优势太明显了。 🙂

[转] 各JavaScript引擎的简介,及相关资料/博客收集

April 20th, 2013 No comments

RednaxelaFX 同学在 ITEYE 上总结了 JavaScript 引擎相关的资源:

http://hllvm.group.iteye.com/group/topic/37596

有兴趣的可以移步关注。

Firefox for Android 的 JavaScript Profiling 方法

April 19th, 2013 No comments

最近需要对手机版浏览器的JavaScript执行效率做性能分析。浏览器选择 Firefox for Android,JavaScript 程序选择 SunSpider、Octane和kraken测试集。

首先要做的就是获得性能测评数据。基本上参照Mozilla的教程就可以做到,但是有几个地方值得记录一下:

  1. 教程中说 Profiler 需要查找“arm-eabi-addr2line”工具,当前版本的Android NDK没有这个文件。找到一个“arm-linux-androideabi-addr2line”,建立一个符号链接,成功骗过了 Profiler。
  2. ADB在Ubuntu下需要sudo启动否则连接不上USB设备。
  3. 手机需要在“开发人员选项”中开启USB调试功能。
  4. Profiler 要求 PC 端开启“devtools.debugger.remote-enabled”选项。(我在手机上手工输入了这个字符串三次,囧)
  5. 开启 Profiling 之后跑 benchmark,有时候会导致 Firefox for Android 和 PC 上的 Profiler 同时假死,停止 Profiling 之后 Profiler 读取数据也可能会假死。多尝试几次总会有成功跑完的时候。(这是个需要解决的问题)
  6. 建议将自动待机(锁屏)时间延长到10分钟以上,在插电源时不关闭屏幕。
  7. 如果不想自己编译,可以下载 Firefox Nightly 安装测试。Release 通道的 Firefox 没有这个功能。

PS:发现 Nightly 经常性的出现输入URL之后网页显示不出来,标签页选择的时候能够看到略缩图,很奇怪的一个bug——一定是我打开的方式不对 🙂

[译] Baseline Compiler in SpiderMonkey

April 19th, 2013 1 comment

这篇博客是对Mozilla这篇文章的简短编译,有兴趣的读者可以看原文。(PS:现在SpiderMonkey的架构越来越像是V8了。)

本周(2013-4-5)我们终于将 baseline 编译器加入了主分支,进入了 Firefox Nightly 版本。从开始开发到今天差不多半年的时间。

Baseline Compiler 是什么?

可以将 Baseline 编译器看成是 IonMonkey 的一个预备编译器(warm-up)。它的诞生使得我们在未来丢弃 JaegerMonkey 成为可能,也因此使得我们有机会大幅度的减少内存占用(在移除了JaegerMonkey之后)。这还使得我们实现新的语言特性、实现新的优化变得更加容易和直观。

引入了 Baseline 编译器之后我们的 SpiderMonkey 在各个 benchmark 上的性能提高了 5%~10%。你们可以在我们的自动性能评测网站上看到结果

为什么又要做一个JIT?

目前 Firefox 有 JaegerMonkey 和 IonMonkey 两个 JIT(这还不算已经移除的 TraceMonkey)。JaegerMonkey能够生成“很快的”代码,而IonMonkey能够生成“真正快的”代码。如果一段代码运行次数频繁,就使用JaegerMonkey编译它;如果之后运行还是很频繁,那就用IonMonkey再去编译一次。这样能够让重量级的优化用在真正需要的地方。但是这种策略的成功,需要仔细的权衡不同优化界别中编译优化的选择,因为编译本身也是需要耗费大量时间的,重量级的优化尤其如此。

简单来说,JaegerMonkey目前被我们当作简单快速的JIT来使用,但是它的设计初衷并不是这个。而 IonMonkey 跟 JaegerMonkey 之间的协作也存在一些问题。最好的解决方式是设计一个跟IonMonkey设计很接近的快速JIT,而baseline就是为了这个目的设计的。

SpiderMonkey的现状

JavaScript代码在SpiderMonkey中的解析过程大致如下:

  1. JavaScript代码首先被解释器解释执行。解释器很慢,但是它可以保证较快的启动速度,并且可以为JIT收集类型信息。
  2. 当一个函数变得“hot”(执行频率达到一定阈值),则调用JaegerMonkey进行JIT,JaegerMonkey使用解释器收集的类型信息来进行优化。
  3. 当函数已经被JaegerMonkey编译,并且执行次数达到IonMonkey的编译阈值(“really hot”),IonMonkey启动,花费比JaegerMonkey多得多的时间生成比JaegerMonkey好得多的代码。
  4. 如果函数中有变量(或其它东西)的类型发生了变化,那么之前JaegerMonkey和IonMonkey生成的jit代码都会被丢弃;以上的三个过程从头开始。

SpiderMonkey 这么设计是有原因的:解释器虽然很慢,但是能够保证执行的结果总是正确的;而IonMonkey虽然能够让编译之后的代码执行速度变快,但是需要花费很多的时间来编译;如果IonMonkey编译的代码执行次数很少,那么反而会导致总体的运行时间变长;而JaegerMonkey处于两者之间,能够用比IonMonkey少的时间生成比解释器速度快的代码,因此它被作为一个折中。

这样的设计很完美,不是么?

不,有几个重要的问题。

问题

  • JaegerMonkey和IonMonkey都没有能力收集类型信息,但是它们依赖类型信息来生成代码。
  • JaegerMonkey和IonMonkey的调用规范是不一样的,这导致两个JIT生成的代码之间的相互调用成本很高。
  • 解释器收集类型信息的功能具有局限性,并不能满足IonMonkey的需求。
  • 类型推断机制需要大量的内存,而类型推断的作者 Brian Hackett 表示把 JaegerMonkey 抛开之后事情会简单很多。
  • 很多 JavaScript 代码执行的次数很少,连 JaegerMonkey 不会被调用。SpiderMonkey 在 SunSpider 测试集得分上落后很大程度上就是因为这个原因。
  • JaegerMonkey 写得太复杂了,我们真的不想继续维护了 🙂

解决方案

我们使用 Baseline JIT 解决这些问题。它的优点:

  • 代码比JaegerMonkey和IonMonkey都简单;
  • 不会失效(invalidate);
  • 可以收集类型信息,inline cache机制可以帮助收集更多类型信息;
  • 比解释器快10~100倍

致谢

Baseline was developed by Jan De Mooij and myself(注:Kannan Vijayan), with significant contributions by Tom Schuster and Brian Hackett. Development was greatly helped by our awesome fuzz testers Christian Holler and Gary Kwong.

And of course it must be noted Baseline by itself would not serve a purpose. The fantastic work done by the IonMonkey team, and the rest of the JS team provides a reason for Baseline’s existence.