Opened 11 years ago
Last modified 7 years ago
#1886 closed enhancement
Upgrade Spidermonkey — at Version 11
Reported by: | Yves | Owned by: | Yves |
---|---|---|---|
Priority: | Must Have | Milestone: | Alpha 16 |
Component: | Core engine | Keywords: | spidermonkey javascript debugger |
Cc: | javierjc1982@… | Patch: |
Description (last modified by )
Tickets related to the Spidermonkey upgrade:
#2126
#2137
#2140
We are currently using Spidermonkey 1.8.5. That's a very old version and newer versions have been improved in performance and stability (memory leaks fixed for example).
A few thoughts about the upgrade:
Version
Mozilla released version 17 which is from the ESR-series of Firefox (longer supported releases) and apparently they will continue releasing standalone versions of Spidermonkey for each ESR-release. Unfortunately some very interesting features like IonMonkey are only available in version 18. Another reason to upgrade to a newer version would be API changes that happen quite often. If we do a lot of work to upgrade now, it's better to already include newer API changes. My current experience from testing is that the API difference between version 17 and 18 probably isn't too big and we could get both versions running to compare them and decide which one to choose.
ESR17 release discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=735599
JIT
We have already enabled JIT (Just In Time compiling) for release builds. Why do we even need to do it "Just in Time" when we (opposed to Firefox) know all scripts before we run them? Version 18 introduced a new JIT compiler called Ion Monkey. This compiler should further improve the optimization for compiled JS code.
There's an interesting blog-post about that topic (also other topics are interesting on that blog): https://blog.mozilla.org/javascript/2012/09/12/ionmonkey-in-firefox-18/
Garbage collection
Garbage collection and memory allocation is a major bottleneck for certain parts of JS code that update a lot of data very often. I made some measurements here: http://www.wildfiregames.com/forum/index.php?showtopic=16721&#entry262183
Garbage collection could be improved by improving the way we handle compartments, especially related to the AI. That's a bit vague but I'm still trying to figure out more about that. An interesting article: http://andreasgal.com/2010/10/13/compartments/ . That article is quite old, but I think the basic concepts explained there are still valid.
Garbage collection can now even be done in a separate thread or we could run it more often (each frame for example) to avoid lag-spikes when it happens. For the AI that problem would probably be solved anyway when we move it to a separate thread.
Since Firefox 16, incremental GC is supported. The question is if that even helps in our situation - probably not. https://blog.mozilla.org/javascript/2012/08/28/incremental-gc-in-firefox-16/
AI in a separate thread
AI calculations should be done in a separate thread. That way we don't have to worry if the AI needs a few hundred milliseconds to do its calculations and the framerate still stays smooth. I've noticed that this task is very much related to the Spidermonkey upgrade because a lot of threading-related aspects of Spidermonkey changed since v1.8.5.
Change History (13)
comment:1 by , 11 years ago
Status: | new → assigned |
---|
comment:2 by , 11 years ago
by , 11 years ago
Attachment: | CGameView_without_CJSObject_1.diff added |
---|
just for reference and discussion in the associate thread
by , 11 years ago
Attachment: | CGameView_without_CJSObject_2.diff added |
---|
just for reference and discussion in the associate thread
comment:3 by , 11 years ago
Keywords: | spidermonkey javascript debugger added |
---|
comment:5 by , 11 years ago
Keywords: | spidermonkey, javascript, debugger → spidermonkey javascript debugger |
---|
r13429 ref'd this ticket because I had to use some hacks to get around AIs sharing data between script contexts. Actually the solution could be much simpler if each AI's data was in a single script context (then ScriptInterface could be used to hold the serializable prototypes, and the implementation wouldn't be AI specific).
Also a heads up since probably these changes will need merging into your local repo, feel free to ask if anything causes trouble.
comment:6 by , 11 years ago
Milestone: | Alpha 14 → Backlog |
---|
comment:7 by , 11 years ago
Description: | modified (diff) |
---|
comment:9 by , 11 years ago
Description: | modified (diff) |
---|
comment:11 by , 11 years ago
Description: | modified (diff) |
---|
I asked about the JIT topic and Ion-Monkey in the jsapi IRC channel. Logs here.
Summary: JIT compiled code can't be saved on the harddisk and used later because it contains memory addresses. However, a function should be compiled with Ion-Monkey when it has been run 1000 times, so everything that runs once per frame should be compiled after about 30 seconds with 30-35 fps, which should be fine for the moment.
Garbage collection occasionally throws away the JIT-ed code. To make sure this doesn't happen, calling "js::NotifyAnimationActivity" should be enough. Check Bug 753630 for more background information about that.