Some interesting developments recently. Firstly, the long-awaited landing of Till Schneidereit's work on self-hosting bound functions in
bug 1000780, greatly speeding up bound functions in common cases (while regressing uncommon ones somewhat). Moving the implementation into JS is sort of the opposite approach to what Chrome did - their implementation was already mostly C++, and they moved it to C++ completely. The new JS implementation in Firefox is
much faster on some benchmarks, including one developed for the new Chrome implementation.
Second, Yury Delendik has been busy making parsing incremental, and enabled asynchronous script compilation in what sounds like an important case:
bug 1236104. 50-80ms main thread jank is not an insignificant amount! I assume pre-loading needs to be active for this to make a difference (e.g. uBlock Origin can turn that off for privacy).
I've also been hearing things about a JITv2 presentation coming up. I'm not sure what that's about - perhaps just a summary of all the enhancements that have been made to IonMonkey and the Baseline Compiler since their inception, or perhaps something new. I believe Hannes Verschore is close to enabling re-use of baseline caches in Ion (
bug 1161516), and work on the new WebAssembly compiler (BaldrMonkey) is well underway (
bug 1234985).
But most of the work going on right now seems to be about standards compliance and code cleanup. Jan de Mooij recently started working on simplifying how eval frames work in
bug 1234845, which should hopefully reduce the amount of confusing code surrounding eval. Shu-yu Guo recently removed the old non-standard array/generator comprehensions in
bug 1220564, which broke some extensions but removed some of the scariest code in SpiderMonkey's front-end.
Jeff Walden has been working on parsing of for-in and for-of loops involving let, another scary and not particularly standards compliant part of SM's front-end. That's spread out across a small constellation of bugs, but should land soon. Terrence Cole continues to work on making the Garbage Collector less insane (with help from Steve Fink, and Jon Coppeard for reviews), replacing old dodgy APIs with new, strongly typed ones that don't allow you to shoot yourself in the foot as easily.
I like to point out code cleanup work in this thread, because the easier code is to understand, the easier it is to optimize further. The SM devs have had to cope with a quickly evolving language and trying to keep up with Google's resources, and this has caused a lot of overly complicated code to accrue throughout the codebase. We're now at a point where performance on the important benchmarks is good, so a lot of long-overdue cleanup work is being done. It feels like that work is never done, but if you compare the quality of the code now to where it was a few years ago, they've definitely made big strides - and we've already seen this pay off, with optimizations that would have been too hard to get right before all the refactoring.
Most projects don't seem to really use it, but I decided to 'join' the jsapi and content teams.
