SpiderMonkey is the JavaScript engine used in Mozilla Firefox. This newsletter gives an overview of the JavaScript and WebAssembly work we’ve done as part of the Firefox 110 and 111 Nightly release cycles.
🛠️ RISC-V backend
SpiderMonkey now has a JIT/Wasm backend for the 64-bit RISC-V architecture! This port was contributed by PLCT Lab and they’ll also be maintaining it going forward. Adding a backend for a new platform is a lot of work so we’re grateful to them for making SpiderMonkey run well on this exciting new architecture.
🚀 Performance
We’re working on improving performance for popular web frameworks such as React. We can’t list all of these improvements here, but the list below covers some of this work.
- We added an optimization for property accesses inside a for-in loop. This lets us avoid slower megamorphic property lookups in React and other frameworks.
- We optimized megamorphic property gets/sets more.
- We optimized atomization more to avoid flattening ropes in certain cases.
- We landed more improvements for our GC’s parallel marking implementation. We’re currently performing some experiments to evaluate its performance.
- We fixed some performance issues with the ARM64 fast paths for truncating doubles.
- We added some fast paths for objects/arrays to structured clone reading.
- We added support for optimizing more relational comparison types with CacheIR.
⚙️ Modernizing JS modules
We’re working on improving our implementation of modules. This includes supporting modules in Workers, adding support for Import Maps, and ESMification (replacing the JSM module system for Firefox internal JS code with standard ECMAScript modules).
- As of this week, there are more ESM modules than JSM modules 🎉. See the AreWeESMifiedYet website for the status of ESMification.
- We’ve landed some large changes to the DOM Worker code to add support for modules. We’re now working on extending this support to shared workers and enabling it by default.
- We continue to improve our modules implementation to be more efficient and easier to work with.
⚡ Wasm GC
High-level programming languages currently need to bring their own GC if they want to run on WebAssembly. This can result in memory leaks because it cannot collect cycles that form with the browser. The Wasm GC proposal adds struct and array types to Wasm so these languages can use the browser’s GC instead.
- We landed enough changes to be able to run a Dart Wasm GC benchmark. We then profiled this benchmark and fixed various performance problems.
- We optimized struct and array allocation.
- We implemented a constant-time algorithm for downcasting types.
- We used signal handlers to remove more null pointer checks.
💾 Robust Caching
We’re working on better (in-memory) caching of JS scripts based on the new Stencil format. This will let us integrate better with other resource caches used in Gecko and might also allow us to potentially cache JIT-related hints in the future.
The team is currently working on removing the dependency on JSContext for off-thread parsing. This will make it easier to integrate with browser background threads and will let us further simplify and optimize the JS engine.
- A lot of changes landed the past weeks to stop using
JSContextin the bytecode emitter, the parser, and many other data structures.