Long-running server processes are not only "not an issue" for the JVM, they're the main use case in which the JVM is superior to AOT compilation! Same is true for C# and the .NET CLR, by the way.

If you're running a Lambda function in which startup time is extremely important, or an embedded application where size and resources are paramount, or even just a short-lived process where you don't care either way... then AOT makes a lot of sense.

But for long-running server processes, just-in-time compilation almost always results is better performance than AOT compilation that cannot optimize at runtime based on what's actually happening.

HN should be full of people who know better, but these discussions feel like piping information into /dev/null. Web devs, students and hobbyists, and other low-information voters just have it in their heads that AOT is always a superior model, and JIT always an inferior fallback, and there's nothing you can say to break through that. There aren't enough people from the business server side world who spend enough time in online discussion forums to correct the narrative.

I agree that a good JIT and the JVM is very powerful, but it's not a silver bullet that magically works for all systems. For example, JIT-compiled code can become uncompiled and recompiled all the time in the same process, resulting in weird performance characteristics. You can definitely fine tune and code in ways that prevent this, and for many apps it won't matter, but when it does matter it's a pain in the butt.

More on this: "Virtual Machine Warmup Blows Hot and Cold" https://arxiv.org/abs/1602.00602

I think there's an important distinction to be made: Theoretically speaking, given that JIT compilers generally care much more about compilation speed than AOT ones, it is not unreasonable to assume that AOT compilers ought to produce more optimized code.

With that said, this is not the case for both JVM and .NET. Stepping away from ought to is, both have JIT compilers which produce better optimized code than their AOT counterparts, due to a variety of reasons including R&D effort done for JIT throughout their history and JIT allowing to dynamically profile and recompile the code according to its execution characteristics (.NET's Tier 1 PGO Optimized and HotSpot JVM's C2).

Theoretically speaking, JITs have access to strictly more information than AOT, so they ought to be better once you amortize out the timing issues. A really good profiling JIT will do a fast-compile pass the first time through, and then progressively re-compile with knowledge gained from profiling during runtime.

“Has more information therefor better optimized” is bordering on a lie, is the problem.

Theres truth to a point I guess, but it’s also true that lots of “more information” is useless, and sometimes harmful to optimization, and additionally that it’s really diminishing returns.

Truth is as long as you’re not over relying on RAII, JVM will virtually never outperform C++.

It's not a lie at all.

That's why there is profile guided optimizations for C/C++.

Which instruments you C/C++ code to collect that needed additional information (on the cost of performance).

Then when recompiling you can feed that collected information into your system.

The problem with profile guided optimization is that it's way more annoying to deploy as on every update you have to deploy it twice once slower then naive and then once faster. And because the slower part might very well be to slow you might want to only deploy it to some nodes of a load balancer and deploy naive compiled versions to the other.

It also means you have a similar slower => faster startup time, excepts it's of your program as whole instead of for each restart of a node.

And while optimized Java likely will never outperform optimized C++ that is Java specific furthermore if we speak about common non manual optimized code which isn't implementing some tight math/CS algorithms (i.e. very common daily code in many companies) then the difference really isn't that big, small enough to make choosing java over C++ for server stuff a "in general" the right choice. (If you are not a company which only gets the "best" programmers like google).

I mean just to put it into context there are companies which had success with stuff like running high speed trading code on the JVM and it was a success. So if you can do that probably Java doesn't have a major performance problem.

> not over relying on RAII

you mean like throwing out all the major improvements of C++ which majorly reduced the probability of non highly expert programmers introducing bugs which could be turned into RCEs?

Suggesting that you shouldn’t be allocating memory and then immediately tossing it doesn’t only suggest that you should practice RCE prone manual strategies.

RAII is dogshit because it encourages and hides the fact of what’s really happening, leading to crazy performance gotchas. Just knowing the gotchas around it is often enough for any half way competent programmer to devise better code.

RAII is the foundation of safe memory management in C++

If the "more information" is useless, it can be ignored. JIT can't possibly be a worse strategy, because a JIT always has the option of simply doing an AOT compile at program start.

That doesn't mean that in practice the JVM is faster than well-written C++; the Java language semantics almost prevent it from doing so in the general case. But in principle, if all else were equal, it should be able to be.

You've not had to diagnose ZK mysteriously hanging or pegging its CPU due to GC or mysterious memory bloat? I have

And the JVM and Java ecosystem has much better profiling tools than when Golang, e.g. has mystery GC pauses.

For a long running, memory safe, server process, there's no other ecosystem (that I know of) that is quite like the JVM.

Consider this: Kubernetes people felt etcd was a better choice, largely because of performance.

https://news.ycombinator.com/item?id=18687516

etcd is pretty good in itself, but Kubernetes has many design choices that do not translate well to other projects, or even to Kubernetes itself.