With Java there's some relation to the native code, so if you reach that point you can use something like GraalVM to get better performance. In fact there's quite a lot of people who check that with large apps, for most cases JITs perform better in runtime and AoT performs better on startup. But for huge apps this might flip.

But the thing is that Java is pretty close to native. Primitive types, object allocation, threads etc. all correlate almost directly to how CPUs and OSs work. So you get a sense of performance and what's expensive/isn't.

With JavaScript there are so many complex abstractions and constructs it's really hard to get a sense of what the final ASM will look like in an optimal case. Unfortunately, some Java changes (e.g. Valhalla) aim to bring some of that lack of clarity into Java. Still, thanks to typing and a simpler syntax Java is MUCH better positioned here than JavaScript.

I agree that with Java you can get close to native performance if you are careful. (I wrote a MCU emulator that beat its C competitor back in 2005, and that's all low-level hackery). But in practice people write a ton of abstraction in Java and programs are quite trashy (i.e. allocate a lot of intermediate objects that are quickly garbage). The APIs and best practices encourage a lot of overabstraction, IMHO, and that leads to big, lumbering programs that struggle to get back to reasonable performance levels with the prodigious efforts of VMs.

> close to native performance if you are careful

I'd like to add that this argument exists for pretty much all "slow" languages and that "if you're careful" often can mean "throw away all upsides your language provides" [1].

Personally, I find these discussions tiring because the ones arguing such points are usually the kind of person that doggedly clings to the "wrong tool for the job".

For example: Although I see rust as the better alternative in many places, I personally find C++ to still be a better language than Java. That doesn't mean I'll insist that Java has no worth or that every program should be written in lower level languages. Horses for courses.

Why can't we just go the Python way and accept the shortcomings of the languages we hold dear?

[1]: Edit: For GCed languages, this often is "avoid the GC at all costs and essentially write less readable C".

What do you mean by exhausting jit caches? Do other VMs limit their size somehow? JSC basically doesn’t.

That doesn’t solve the problem of course. I have this metric that I use to philosophize about this: SIPS, or static instructions per second. If your program has low SIPS (I.e. it’s the benchmark of HotSpot’s wet dreams or OP’s post) it means that the total code is small and it runs a long time - so the JIT will go on a rampage early on and then you’re good. If the program has high SIPS, then the JIT will still be catching up when the program terminates. Most real things that aren’t web servers have low SIPS.

Reflecting more on this. AFAIR Hotspot does have a hard limit on the amount of machine code it will generate. V8 has a hard limit on the heap size, and code pages are part of that. But both of those are pretty big numbers, so if you are hitting that you are probably huge already. But generally there are counters in the metadata for functions or classes, depending on the system, that limit how many times a given unit might be recompiled, typically to limit the damage deopt loops can do. So programs end up gradually leveling off as they hit those limits.

I haven't really paid attention to V8's policies for years, but generally speaking, it still does this to some extent.

I think of SIPS as basically the resident set size for code. Depending on how the system ages your code, you might be stuck with unused JIT code until it can be recycled, if at all. V8 used to have code aging and the implementation was a huge bug farm. I am not sure if that survived the switch to TurboFan/Ignition. Of course, V8 GC's code about as aggressively as it compacts the old generation.

JSC limits recompilation only in the sense that we have exponential back off on each jettison. But that means that a sufficiently hot function will keep getting recompiled forever even if speculation is permabroken in that function.

Other than that JSC has only very weak heuristics for aging out code. And on sufficiently empowered devices our JIT pool is hundreds of megs.

So, we will happily compile your whole program with the jit if your whole program is warm and runs long enough.