3 ms·
Don't build a JavaScript JIT. A fast interpreter will be enough
- makapuf 3y agoI 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?
- Onavo 3y agoOP is the author of the ladybird browser engine
- Twirrim 3y agoThere 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.
- pipeline_peak 3y agoI’d rather hear what Lars Bak has to say. He’s the one in charge of the JS engine most of us use…
- olliej 3y agoTo 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)
- lttlrck 3y agoGoogle 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 https://v8.dev/blog/maglev
- olliej 3y agoEvery 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)
- paddim8 3y agoAndreas 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.
- high_na_euv 3y agoJS JIT is source of a lot of serious CVEs
- olliej 3y agoHonestly 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).
- deleted 3y ago[deleted]
- samsquire 3y agoA 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.
- potsandpans 3y agoThis falls under the category of extraordinary claims require extraordinary evidence
- ksec 3y ago>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.