Archive

Archive for the ‘SpiderMonkey’ Category

WebAssembly 要开始并入 SpiderMonkey 了

November 13th, 2015 1 comment

从 BMO 上看到的(Bug 1224389), 速度真是快.

目前来看是要重构 OdinMonkey (JIT for asm.js), 共享后面的部分.

这样会不会又出现一个 xxxMonkey …

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 这样的临时文件夹. 所以在打包的时候需要检查相关的目录中没有中间文件或临时文件.

Project Candle: Mozilla 的低功耗改进计划

September 14th, 2015 No comments

在发起了性能改进计划(AreWeFastYet.com)和内存使用改善计划(AreWeSlimYet.com)之后,最近 Nicholas Nethercote 发起了新的功耗改进计划: Project Candle。

Nicholas Nethercote 是 Valgrind 的主要作者,背着顶会论文2000+次引用的光环 🙂

具体如何改进我还一窍不通,不知道低功耗怎么做的。Mozilla 已经建立了专门的 IRC 频道和邮件列表,具体可以看 Candle 的项目Wiki

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.