jandem

Here's a write-up for one of the bugs they found: https://red.anthropic.com/2026/exploit/

Crypto miners written in JS existed long before WebAssembly. Back then people also compiled large C++ code bases to (highly obfuscated) JS code and out of these heroic efforts grew asm.js which then evolved to WebAssembly. WebAssembly is a much better compile target than JS with more low-level types and primitives, but it's very similar to JS code in what it can and can't do in the browser.

Compiling a C++ application to megabytes of JS code doesn't make the result any more open-source or non-DRM than compiling the same thing to WebAssembly (you could translate Wasm to the equivalent but slower JS code).

Nice to hear from you! Yes it was a very reasonable choice back then, before (enormous) asm.js and Wasm functions.

The compiler wasn't really designed for these huge graphs, but fortunately a lot of the issues can be fixed incrementally and it's still holding up well.

The point is that Musk has been talking a lot about being a free speech absolutist. He even said this last month:

> My commitment to free speech extends even to not banning the account following my plane, even though that is a direct personal safety risk

And now he's banning accounts. That doesn't make sense for a free speech absolutist.

I think part of this is just time to get used to something new? You might notice some improvements too, for instance only after I started using Fastmail I realized the Gmail UI can be pretty slow and heavyweight although I never noticed this before.

This behavior is defined in the HTML spec, here:

https://html.spec.whatwg.org/multipage/browsers.html#crossor...

> With Fastmail or another provider, you're trusting another corp.

You're trusting a corp that offers customer support, a service you pay them for. With Gmail you're completely on your own because you're only a small cog in the massive data mining machine. That's a pretty big difference.

That said, it's a good idea to set up a custom domain with a trusted registrar.

I migrated to Fastmail a few weeks ago. I'm really happy with it and I wish I had done it years ago. Many features. The web interface and apps feel a lot faster than Gmail.

Pro-tip: use a custom domain so that you can easily switch e-mail providers in the future without vendor lock-in. It's also very easy to add aliases in Fastmail.

> Plus after the import is finished, it will still periodically bring over any new emails received to the Gmail account.

Another option is to let Gmail forward your email to the new address.

> It’s a big deal and everyone who contributed should be super proud.

Thanks! We actually haven't really analyzed Speedometer (and most other benchmarks) yet with Warp so I expect this number to improve the coming months. The design seems to be holding up well and we're really excited about building on this.

SpiderMonkey dev here. Does this reproduce for you with a clean profile? Because I just tried this with 78.0b9 too and for the first one, Local (original), I get 6.7 ms in the Web Console, very similar to what I see in Chrome. I didn't look at the other ones.

For background, see http://exple.tive.org/blarg/2019/04/26/synchronous-text/

> So why aren't people just shipping straight up LLVM intermediate language VMs and instead go through wasm?

This is answered in the WebAssembly FAQ: https://webassembly.org/docs/faq/#why-not-just-use-llvm-bitc...

> They all looked glum, and said "There is no alternative".

Most people that I know here in the Netherlands prepare lunch at home and bring it to work or school. I work from home now and still usually eat simple sandwiches for lunch so at least for me it's not about "no alternatives".

It gives me more time to go outside or stop working early - I honestly don't want to spend (at least) an hour going out just to have lunch and then a similar ritual in the evening for dinner.

> Is that the difference, or am I missing something else?

That's part of it. The generated interpreter should be a bit faster for simple instructions because of the reason you give (also: things like debugger breakpoints have more overhead in the C++ Interpreter).

However, the bigger speedups are because the generated interpreter can use Inline Caches like the Baseline JIT. The C++ Interpreter does not have ICs.

As far as I know V8 has a generated interpreter and an optimizing JIT (Turbofan).

In Firefox we now have a generated interpreter + a Baseline JIT on top of a mostly shared code base. I think that's a pretty nice design/advantage.

> Given all that, why are we still creating entirely separate engines that are made differently, yet do the same.

To name one reason: would we have asm.js/Wasm instead of (P)NaCl without Mozilla's work on asm.js optimizations in SpiderMonkey?

> One thing that wasn't clear to me from this post is why they still need the C++ interpreter at all.

A lot of code on the web is very cold (executed once or twice) and for such code the Baseline Interpreter would add some overhead (requires allocating a JitScript storing the IC data for example and we would then spend more time in IC code as well). It's possible this could be mitigated or fixed with additional work, but we need to keep the C++ interpreter anyway (not all platforms have a JIT backend and it's useful for differential testing) so it's not a priority right now.

Many (most?) people on Rust's Core/Governance Teams don't work for Mozilla (anymore).

See https://www.rust-lang.org/governance/teams/core

SpiderMonkey dev here. As others have mentioned, Cranelift is one component that's being written in Rust. Eventually we want to use Cranelift as compiler backend not just for WebAssembly but also for JS. After that it might be feasible to port more of the JS JIT to Rust. It might also make sense to use Rust for the parser or regular expression engine, who knows.

There will probably always be C++ code in Gecko, but I firmly believe that writing more components in Rust instead of C++ will (in general) improve security and developer productivity.

It still amazes me that we're actually shipping a browser with a CSS engine (and soon graphics engine!) written in Rust. Even more amazing is that these components are mostly shared with an entirely different browser engine.

> Function calls from WASM to JS don't seem to have improved so much.

Yeah, Wasm => JS calls used to be reasonably fast because we had optimized that before. The work described here made that path much nicer, though (a more unified stack layout for JIT/Wasm frames) and also a bit faster still.

JS => Wasm calls being slow was one of the big performance cliffs in SpiderMonkey and I'm really glad that's fixed now.

I get a certificate error on Firefox Nightly. This is likely caused by https://wiki.mozilla.org/CA/Upcoming_Distrust_Actions

> The author is able to achieve a speed-up of ~4x which is close to the 5.89x achieved by the Rust implementation.

This is not a fair comparison because the author made algorithmic improvements that would also improve the wasm version if applied to the Rust code. Source: https://twitter.com/mraleph/status/965616993310265344

I work on SpiderMonkey JS performance (and got mentioned in the article for fixing a perf bug!) and this is exactly the point I wanted to make. If you're not a VM engineer, it's much harder to write fast JS. Wasm also gives you much more predictable performance across engines, without requiring (often engine-specific) 'hacks' like function cloning.

The JS version is slow in Firefox because of a silly perf cliff, I filed a bug [0]. A quick fix for that improves the JS version from ~400 ms to ~180 ms for me locally. ~140 ms if I disable the Nightly-only GC poisoning.

edit: the JS code is a bit buggy: it does |if (Math.abs(dblDiscriminant) < 0.01)| in the |intersection| function, but dblDiscriminant is a var set in the next loop! Math.abs(undefined) is something we can easily optimize in the JIT, but really the JS code is broken. Folding this in our JIT [1] improves this to < 130 ms for me.

Please let us know if you run into JS perf problems, these bugs are usually easy to fix.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1425687

[1] https://pastebin.com/CzfP5vQj

Thanks. Removing these hooks would have been a lot more complicated 6 years ago: I'm pretty sure the new WebIDL DOM bindings got rid of many of them over the years. I also replaced some of the Class hooks with proxies, did proxies even exist back then? :)

> Now I'm really interested in the SpiderMonkey/V8 thing.

I think SpiderMonkey is 60x faster than V8 there because of an optimization we have to avoid quadratic behavior while flattening ropes, it's described here: http://searchfox.org/mozilla-central/rev/0f92c398ce929a3f3d9...

Basically JS engines do string concatenation lazily: they create a rope, and then the rope is flattened when needed [0]. When appending/concatenating one character at a time and flattening after each concatenation, we avoid quadratic behavior (copying the same chars over and over again while flattening) by overallocating so we can simply append while flattening. The source code comment has the full details.

[0] https://en.wikipedia.org/wiki/Rope_(data_structure)

The next Firefox Nightly build should get 84% on that page, much closer to Edge than Firefox 44 (74%).

I work on SpiderMonkey and I'm super excited about this news. All JS engines have added more-or-less similar performance optimizations but often implemented differently and I'm really interested to see what the Chakra team did. I'd be happy to write a blog post on it next month, if people are interested.