Archive

Posts Tagged ‘SpiderMonkey’

Firefox/SpiderMonkey的龙芯MIPS64后端

November 1st, 2015 1 comment

不久之前写过一篇博客[1]为龙芯CPU”辩护”, 解释为什么龙芯CPU的JavaScript性能会很低.

就我个人的经验而言,龙芯的 SunSpider 性能差异更多的应该是在软件层面。现代的浏览器都通过(多个层级的)JIT来对JavaScript进行加速,开启和关闭JIT的SunSpider、Kraken、Octane 跑分差异可能会相差20~30倍。使用 iPhone 的同学可以在 Safari 和微信自带的浏览器中测试对比下速度差异(iOS 中只有 Safari 可以开 JIT)。三大开源浏览器JIT引擎对于龙芯采用的MIPS后端的支持都还很初级,甚至还不能正常使用。龙芯官方[6]和开源爱好者[5]的数据也印证了龙芯CPU跑 JavaScript 的尴尬。软件层面的缺失,或者往大了说,生态环境的问题,也是龙芯(MIPS架构)需要面对的一个大问题。

但是现在情况可能就要大不同了. 中科梦兰(龙芯系)的 heiher[2] 同学在今年开始频繁地向 Mozilla 提交MIPS64后端代码[3], 相信启用了JavaScript JIT的 Firefox 在龙芯CPU会有很大的性能提升. 到时候(瞎猜)快个20倍也说不定哦 😉

[1]: 龙芯CPU的JavaScript性能

[2]: http://hev.cc

[3]: Bugzilla User Activity

SpiderMonkey 的版本号在代码中是如何传播的

October 27th, 2015 No comments

编译好的 SpiderMonkey JSShell 是有一个版本号的. 通过运行 js –version 可以看到(是Mozilla的版本, 不是1.7+,1.8这样的JS_VERSION). 例如我的构建版本输出的是44.0a1. 这个版本上是Mozilla仓库统一的版本号. 这个信息并不保存在 SpiderMonkey 源代码目录中, 而是保存于 Mozilla-Central(or gecko-dev) 仓库的 config/milestone.txt 目录下:

文件很简单. 就只有一个版本号.

之后, 在 SpiderMonkey 的 configure 脚本中, configure 脚本调用 $srcdir/python/mozbuild/mozbuild/milestone.py 读取 milestone.txt 并返回版本(子)字符串. 在脚本配置过程中使用到了 MOZILLA_VERSION、MOZILLA_UAVERSION、MOZILLA_SYMBOLVERSION 三种版本形式:

其中 MOZILLA_VERSION 又进一步的被分成 MOZJS_MAJOR_VERSION、MOZJS_MINOR_VERSION、MOZJS_PATCH_VERSION、IS_ALPHA 四个变量:

在本例中分别对应 44, 0, 1, a.

configure 获取到相关的信息之后, 将其写入到 js-config.h 以及 js-confdefs.h 两个文件中, 使得 JSShell 能够获得版本信息. 同时, configure 也将该信息写入 Makefile 文件, 用于在 make source-package 命令式, 将版本号正确的传递给 make-source-package.sh 脚本. make-source-package.sh 脚本可以简单的理解为一个打包脚本, 将 SpiderMonkey 在 mozilla-central 仓库中所有依赖的文件都抽取出来, 用于单独发布.

如何打包 SpiderMonkey 代码

October 27th, 2015 No comments

SpiderMonkey 提供了一个脚本make-source-package.sh来打包 SpiderMonkey 代码. 在configure生成的js/src/Makefile中, 包含了打包脚本的使用方法.

 

如果是在Debian/Ubuntu或Fedora这样的Linux系统下, 可以直接替换成以下命令生成:

对于make source-package而言, 生成的代码包会放置于./dist目录下. 注意目前make-source-package.sh并不能忽略掉js/src中的_DBG.OBJ_OPT.OBJ 这样的临时文件夹. 所以在打包的时候需要检查相关的目录中没有中间文件或临时文件.

SpiderMonkey 开始计划提供 JS 覆盖率信息

September 9th, 2015 No comments

Mozilla Bugzilla 上已经有了对应的 meta bug. 具体的实现可能需要再等一到两个月.

Nicolas B. Pierron [:nbp] 2015-07-30 08:05:23 PDT
This is a meta bug to add Code Coverage for JavaScript code executed in SpiderMonkey. We have multiple reasons to do that:

The most important is to support release management team, by producing Code Coverage information over executed JavaScript code, and producing gcov-like data files. This would help improve the quality of Firefox, and help evaluate the quality of our tests to accept/refuse new features.

The second reason is to expose this information to the dev-tools, such that JavaScript developers do not have to instrument their code to have code coverage results within the dev-tools.

The third, if the overhead is neglectable, is to make use of the same information to improve IonMonkey register allocation and removal of unused basic blocks ahead of time.

afl-fuzz vs. mozjs: 1st round.

August 13th, 2015 No comments

第一轮, 随机从 mozilla-central 的回归测试集中选择了几个js文件, 没有使用字典, 默认 afl-fuzz 配置.

结果: 一个 crash 都没有发现.

分析: 这个是合理的. 没有字典直接 Fuzz, 绝大部分都过不了前端的 Parser. (绝大部分的意思是我没有做统计, 直观猜测的)

afl-fuzz-vs-mozjs