Don't build a JavaScript JIT. A fast interpreter will be enough | Hacker News Reader

Don't build a JavaScript JIT. A fast interpreter will be enough

twitter.com

27 pointsgoranmoomin13 comments

JS JIT is source of a lot of serious CVEs

Honestly IMO it's more an enabler for CVEs - it provides a mechanism for attackers to get arbitrary code exec if they can circumvent the protections on modifications to the JIT region - the bugs that are the root of the exploit seem to mostly be GC issues (which makes sense as GC issues give you various analogies to OoB, type confusion, UaF, etc that are the basic units of exploits).

A mature production grade optimising JIT compiler codebase feels very it is weighty to understand for a newcomer in order to add value to the space because there's so much content to learn and be familiar with.

Godbolt for compiler internals and each compiler internal pass would be useful for me.

This falls under the category of extraordinary claims require extraordinary evidence

>extraordinary claims

Nothing extraordinary, in fact if you have been following the development of JS VM for the past 10-15 years this should have been well known.

I’d rather hear what Lars Bak has to say. He’s the one in charge of the JS engine most of us use…

To my knowledge Bak has not been involved in V8 for many years, but also from my direct experience the overwhelming majority of JS executed is dominated by latency rather than through put (which is Kling’s point)

The original v8 was a significant change in that it showed that it is possible to optimize - to machine code - js in a way that offers sufficient perf to make it an enabler of more complex code.

however that came at a significant increase in real world page load performance. Dealing with that latency regression was a significant challenge when originally introducing a JIT to JSC.

Even today it is amazing how little emphasis is seemingly placed on interpreter performance by chrome and Firefox, as it dominates page load performance and latency for almost all real world pages. (I’m actually somewhat curious what % of js source seen by engines ever actually reaches a point where gains from native codegen cover the runtime cost of said codegen)

Google has spent huge efforts optimizing page start up times, this overview is from late last year.

Maybe not "interpreter performance" per se, but it's in the area and focused on page load time.

https://v8.dev/blog/maglev

Every browser devotes huge amounts of effort to PLT because that is the place where performance matters for most sites.

JS interpreter perf is a significant part of the latency, which is why it's weird to me that so little effort is placed into that vs the ever increasing complexity of JIT optimizations that are only important for a minority of websites.

There are also security reasons for improving interpreter perf as it gives you the option to have the JIT disabled for more processes (at the extreme there's iOS "lockdown" mode which disables the JITs everywhere)

Andreas worked on performance for Safari and has also talked to several other people who have worked with the JavaScript engines of major browsers and they have all come to the same conclusion.

I don't have a twitter account, so I don't see the whole thread. I suppose the thread is itself interesting ; Is there a way for people like me to understand the context?

OP is the author of the ladybird browser engine

There doesn't seem to be a thread, just that one tweet. There's reasons that the companies they're coming from have built JIT for Javascript, so I assume the angle here is just to avoid unnecessary complexity until it becomes absolutely necessary. Which is pretty much solid advice regardless of what you're building. In this case, though, they're saying to make the interpreter shine, until a lack of a JIT becomes a problem.

Reply on news.ycombinator.com