V8 Blog

I was struggling to figure out how this could even be exploited. Following a trail of links led to <https://v8.dev/blog/control-flow-integrity#corrupted-syscall-arguments>, which motivated the API. It gives the example that "if a thread calls munmap on a corrupted pointer, the attacker could unmap read-only pages and a consecutive mmap call can reuse this address, effectively adding write permissions to the page."

So, a hypotetical attack would involve 1) Corrupt a pointer passed to munmap, such that it points to some believed-executable part of the code (e.g. the MPEG decompression library code, or something like that). 2) Cause a future `mmap` to reuse that page with writable permissions, and in particular have the returned page be one that is eventually destined for being marked executable (e.g. the caller should be the JIT compiler). 3) Modify the writable page to control code you want at a known address (e.g. by having the JIT emit code you want, or by having another vulnerability that writes to this address). 4) Have the target page marked executable (e.g. by finishing the JIT compilation). 5) Finally, call the executable page (e.g. attempt to decompress an MPEG file).

In the absence of already having arbitrary code execution (which would make the whole process moot), this whole thing requires a JIT compiler (since it has to already contain a call to `mprotect` that sets a page executable), and either the JIT compiler has a bug or a separate thread performs step…

(I work on Figma's renderer, but I don't know much of the history of it.) The speculation there about C++ vs JS performance in Figma seem about right to me.

Notably, some Figma views (like when you click the "play" button to view the prototype) render Figma documents using JS, no* Wasm. They are more or less comparably as fast as the C++ renderer, in part because much of the heavy lifting is done by GPU code that isn't C++ or JS anyway.

The main place I think we've seen a performance difference is, as the post observes, high throughput scenarios: for example, decompressing a large file, or parsing through a large binary serialization of a file. But particularly in a browser setting you end up wanting to get your data into a browser API at some point and that often ends up meaning copying data around that eats your performance.

The other main difference that's worth pointing out is memory efficiency. For example, pointers in Wasm are currently 32 bits, which means (at least in principle) a massive graph -- such as a Figma document DOM! -- can be represented with 32-bit C++ pointers rather than 64-bit JS pointers. But even that distinction is not so clear in the presence of pointer compression [1] and there are other graph representation options etc.

In all, my conclusion is that performance does not obviously derive from tool choice because there are so many confounding factors including algorithm choice and path dependence. For another example of this, I often…

My biggest pointer would be to remember that Java & JavaScript aren't named that way by coincidence. They're two different approaches to a similar problem. Java suffers from Enterprise Development (eg: Enterprise FizzBuzz[0]), JavaScript suffers from Ultimate Accessibility (eg: how many questions on Stack Overflow conflated jQuery and JS?).

> How should exceptions be managed? [...] Has there been a debate about best practice? Where can I find it?

I suggest you handle the errors you can and otherwise let it crash.[1][2] Debates in NodeJS-land have steered towards more monadic/Result-like structures and working synchronous-looking try/catch onto async/await. NodeJS and its various components are open source, you'll have a lot of luck looking around on GH for issues & PRs related to a feature -- same for the language, ECMAScript[3] officially.[4]

Since you mentioned Clojure, have you looked at ClojureScript?[5] That may be a good entry to JS authors & articles you'd enjoy.

> I have the impression that NodeJS is a bit more magical than the JVM [...] Is that correct? Where are good resources on this subject?

As other replies have mentioned, you're really talking about V8[6] for the "JSVM" executing that code. A thing I've seen throw some people for a loop is how minimalist the specification actually is.[7] The magic in NodeJS is certainly from V8 and the rate of optimizations there but also libuv,[8] what actually powers the infamous event loop.

Hope that helps!

[0]:…

It can sometimes be difficult to predict what will cause performance regressions when developing an application or web server with test data. So you do your best with what you know at the time of release, and then deal with performance issues when you know what is causing regressions (e.g. saved searches) and can then make measurements and profiling to see what exactly is causing the issue.

Likewise, improving performance pushes the limit at which performance regressions happen allowing more data (documents, triangles/pixels, etc.) to be processed. This allows things like more complex game graphics. That in turn makes it harder to improve performance for the next round (more advanced triangle/face culling and pre-processing).

There can also be trade-offs with things like data layout, memory usage (caching and memoization), or implementation. For example, when processing XML/HTML data you could use DOM (more memory and upfront parsing, but easier to perform complex queries across the data), SAX (less memory, but more complex to process due to tracking state), or reader API (similar to SAX but a different processing model).

There can be challenges with various features, such as type checking with higher-order generic types. Others add various levels of overhead, such as parsing a program, constructing an AST (Abstract Syntax Tree), generating an IR (Intermediate Representation), the optimization passes and final code generation.

JavaScript evaluation for example is…

Usually software architecture is not language-dependant, so your knowledge from Java could be used here. For example, you can do hexagonal architecture in NodeJS. All of what you learned about exceptions can also be applied here. Probably most of what you learned about static typing too, if you work with TypeScript.

I think another part of learning JavaScript is forgetting what you learned in other languages and embracing JavaScript. At work most of the JS/TS code is namespaces and plain functions, with the occasional object when that makes sense. We don't use much the dynamic nature of the language in application code, but for testing we use it a lot.

For the performance part, I agree, it's hard to find resources. Part of it is because JS is "good enough" for most server-side software: the language is fast and asynchronous IO helps a lot. Most high-level advice is about being nice to the JIT: write code as if it was statically typed, let the JIT make easy assumptions and don't break them (objects that don't change, arrays used as arrays). Part of it may also be because the V8 team is constantly hard at work to improve performance. Their blog (https://v8.dev/) is a great read, I learned a lot here. There's another high-level advice that works everywhere: try to make a stateless app, so that scaling horizontally is easy.

(I work on SpiderMonkey.)

Benchmarking is hard. It is very easy to write a benchmark where improving your score does not improve real-world performance, and over time even a good benchmark will become less useful as the important improvements are all made. This V8 blog post about Octane is a good description of some of the issues: https://v8.dev/blog/retiring-octane

Speedometer 3, in my experience, is the least bad browser benchmark. It hits code that we know from independent evidence is important for real-world performance. We've been targeting our performance work at Speedometer 3 for the last year, and we've seen good results. My favourite example: a few years ago, we decided that initial pageload performance was our performance priority for the year, and we spent some time trying to optimize for that. Speedometer 3 is not primarily a pageload benchmark. Nevertheless, our pageload telemetry improved more from targeting Speedometer 3 than it did when we were deliberately targeting pageload. (See the pretty graphs here: https://hacks.mozilla.org/2023/10/down-and-to-the-right-firefox-got-faster-for-real-users-in-2023/) This is the advantage of having a good benchmark; it speeds up the iterative cycle of identifying a potential issue, writing a patch, and evaluating the results.