Changes between Version 11 and Version 13 of Ticket #1886


Ignore:
Timestamp:
Sep 21, 2013, 5:30:41 PM (11 years ago)
Author:
Yves
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1886 – Description

    v11 v13  
    55[[BR]]
    66
    7 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).
     7Related bug in Spidermonkey:
     8[[BR]]Meta-Bug for performance related 0 A.D. Bugs: [https://bugzilla.mozilla.org/show_bug.cgi?id=897962 Bug 897962]
     9[[BR]]
    810
    9 A few thoughts about the upgrade:
     11Also check [http://www.wildfiregames.com/forum/index.php?showtopic=17289 the forum thread] for the current status.
     12
     13We are currently using Spidermonkey 1.8.5. That's a very old version and we need to upgrade to a newer version for various reasons. Unfortunately that's not very easy because the API changes quite often.
     14
     15Reasons for upgrading:
     16- Switching earlier avoids writing too much code for the older API that has to be changed later
     17- Only when using a supported version it's possible to fix Spidermonkey security issues (I know that 0 A.D. itself most likely has more security issues at the moment)
     18- Learning how the new API works with multi-threading is important for our AI multi-threading design.
     19- Performance: During the work on upgrading we figured out that performance currently isn't much better in the new version compared to v1.8.5. The huge improvements from benchmarks don't translate to most real world applications. Loading random maps is a lot faster, but that's the only thing at the moment. It's still possible that the performance will improve once the most important bugs in Ion Monkey and Baseline are fixed.
     20- If we find bugs in v1.8.5 we will never get support from Mozilla. If we use the current version or if the same bug also affects the current version, getting help is much more likely.
     21- Getting new features into the official version of Spidermonkey is also only possible when we use the current version.
     22- Many Linux distributions will use the new ESR versions of the standalone library. It's better to use that library provided by the system instead of bundling our own version. v1.8.5 won't be supported by Linux distributions forever.
    1023
    1124== Version ==
    12 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.
    13 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.
     25Mozilla plans to release standalone versions of Spidermonkey for each ESR-release.
     26Currently we don't know which version of Spidermonkey we will use because some performance bugs need to be fixed in the current version of Spidermonkey.
    1427
    1528ESR17 release discussion:
     
    1730
    1831== JIT ==
    19 We have already enabled JIT (Just In Time compiling) for release builds.
    20 Why do we even need to do it "Just in Time" when we (opposed to Firefox) know all scripts before we run them?
    21 Version 18 introduced a new JIT compiler called Ion Monkey. This compiler should further improve the optimization for compiled JS code.
     32The Just In Time compiler creates optimized bytecode or even native assembler code for functions or loops that are called often. That's something different than the compiling which translates the scripts to bytecode in the first step.
    2233
    23 There's an interesting blog-post about that topic (also other topics are interesting on that blog):
    24 https://blog.mozilla.org/javascript/2012/09/12/ionmonkey-in-firefox-18/
     34It's currently not possible to JIT-compile the scripts before they are executed or even store them in JIT-compiled form on the disc.
    2535
     36Using js::NotifyAnimationActivity it's possible to prevent the garbage collection from collecting generated JIT-code (and forcing recompilation). Unfortunately this only works if js::NotifyAnimationActivity is called at least once a second. With big lag-spikes, especially in debug mode, this can't be guaranteed at the moment.
     37At the moment I'm working around this by modifying Spidermonkey's Runtime.cpp directly. I'll have to find a better solution.
    2638
    2739== Garbage collection ==
     
    3547
    3648Garbage 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.
    37 
    38 Since Firefox 16, incremental GC is supported. The question is if that even helps in our situation - probably not.
    39 https://blog.mozilla.org/javascript/2012/08/28/incremental-gc-in-firefox-16/
    40 
    41 == AI in a separate thread ==
    42 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.
    43 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.