In Chromium you can turn off V8's JIT compiler for this reason. You can even opt in again for sites you trust that need the additional performance.

The additional performance from the JIT is actually really small for most tasks. It should, ideally, be disabled by default. For your average JS you get <10% performance gain. Most of the cost is browser API, not JS, so the performance is underwhelming.

It’s only very heavy calculations that see a boost in performance. But, realistically, how many websites require this or currently use this today? <1%? Maybe <.1%?

This is pretty typical across JIT engines, too. PHP also sees only a slight increase in performance from the JIT. Because of the nature of PHP applications, most time is spend on the network and database. Only very CPU-heavy code sees a significant speed up.

That’s even the case for C#, which is why the dotnet runtime only conditionally JIT compiles code. Only hot path code is eligible for JIT compilation.

That is surely not the case for C#, contrary to most JVM implementations, on the CLR CIL is always jitted before execution since .NET 1.0, and this not taking into account AOT scenarios like NGEN (since .NET 1.0), and everything that came later as AOT toolchains.

The only .NET implementations that interpret CIL were the .NET Compact and Micro frameworks due to hardware limitations, nowadays mostly gone as .NET workloads, and alternative implementations like Mono.

You’re correct, where I got confused is the lazy per-method JIT and the tiers of JIT optimization. My understanding is that dotnet only compiles on first function call, or when it has to for things like generics. So, some code is never compiled if it’s never executed. And then, functions will be re-JIT at higher optimization levels under certain conditions later. You certainly know more about this than me, but yes I was wrong about conditional JIT.

I’ve done that long ago. In fact on iOS it’s simpler: since Apple doesn’t allow third party browsers to use the JIT, using any browser other than Safari will disable the JIT.

Chrome on iOS has always been JIT'd because it used a WKWebView.

It still uses a WKWebView today, even in the EU, despite Apple now allowing alternative browser engines in the EU as of 2 years ago.

I'm sure Chrome will eventually ship Blink+V8 in the EU. It will take some time

This hasn’t been true in over a decade.

Do you have any citations for this? Not that I doubt you but I’d like to read more about it.

Yes, the V8 team released a blog when they introduced jitless mode: https://v8.dev/blog/jitless

In synthetic benchmarks, there was a 40-80% reduction in performance when disabling the JIT. But in a simulated test on YouTube.com, the performance delta was only 6%.

This isn’t the best source as it’s a bit old, and it wasn’t just JIT that was disabled. But the core idea is the same: calculation-heavy code can see an improvement, but most code won’t. Why this matters is how people actually use JS on the web. It’s not for cryptography and such, it’s to manipulate the DOM.

Microsoft also has some benchmarks here: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

For PHP the RFC analyzes it: https://wiki.php.net/rfc/jit

We see a similar pattern: in synthetic benchmarks, the performance gain is large. But Wordpress, by far the largest PHP deployment in the wild, only saw ~3% performance gain. It again comes down to how PHP is used. It’s mostly HTML construction and database calls, neither of which will see any performance gain from a JIT. And, PHP has extensions, where most heavy code is moved to. Things like cryptography are done in PHP extensions, in C, where the JIT doesn’t matter. I’m more familiar with PHP, so I’ve known about the history of PHP not shipping a JIT due to the lackluster performance.

I'm glad I've already done that! I haven't seen any difference in performance like others mention though. Weird. The only override I've made is for a website which needs to run some client-side cryptography code and it would take ages without the JIT.

> Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox.

It's easy to be safer, as long as performance can be sacrificed for it.

We live in a world where my laptop is forced to waste tons of computational power on immensely bloated websites even with ad-block, with now even having to worry about agentic bullshit that I didn't ask for, and plenty of others apparently still think throwing computational cycles at cryptocurrency is good for anything.

Complaining about a relatively small performance price for Fil-C in that context honestly feels like that one famous newspaper photo of a smoking pregnant woman drinking a beer with a caption saying she's wbrried about the effects of the loud construction noises next door on her unborn child.

Except even that is wrong, because at least she had a point about the construction noises, while this is more of a "refusing to eat your vegetables" kind of situation.

We also live in a world where site owners purposely put anime cat girls on their websites that serve no purpose then to waste cpu cycles.

Using personal websites read by a handful of programmer nerds that work fine if you turn off javascript to justify literally everyone else being forced to navigate bloated, broken company websites isn't particularly convincing as an argument against memory-safe C imo.

Perhaps you do.

> easy to be safer

It took over two years and help from contributors to get to the point where WebKit could be made fully memory safe.

Sure, but compare that to the effort it would take to have the same safety guarantees without any drop in performance.

When Chromium and V8 are written in a memory-safe language then I might believe this.

Yes, if your JavaScript engine is written in C++, it’s going to be very hard to avoid very gross bugs. We have better options now.

The ability of adversaries to find and exploit very gross bugs in C++ codebases should have already compelled the industry to move to memory safety. Now that AI has democratized the ability to scour C++ codebases for really gross and exploitable bugs, I should think that our hands are at last being forced. I’m not impressed by what I’ve seen in the industry with respect to taking memory safety seriously.

Exactly this. This is a never ending problem with C/C++ and it's these same memory corruption CVEs appearing all the time.

I also cringe at projects that "compile C to WASM" and then believe that it is immediately "memory-safe". (It really is not.)

The only exception for C/C++ projects is Fil-C which that is memory-safe. New projects at this point should just consider using Rust instead.

A JIT by definition bypasses the safety mechanisms of whatever language you write it in. Think before you post.

I believe programmers still write in C(++) after memory safe options, in order to continue being occupied afterwards, fixing the bugs that will arise. Without criminals, police is obsolete.

> WebKit MiniBrowser compiled with Fil-C

Sir, do you happen to have instructions for doing this? We who benefit from your philanthropy salute you.