[darksaints]

The problem is that Intellij is written in Java, using the hotspot JVM, which is JIT compiled.

But IDEs, especially fully featured IDEs, are a terrible type of workload for JIT compilation. They're full of branches, which can easily cause recompilations, and the breadth of features mean that there is never really a spot hot enough to stay compiled outside of the editor itself.

I really wish AOT compilation was taken more seriously in the JVM world. Yes, I know about graal native-image and the various embedded commercial JVMs, but those are niches. It would be great if I could just precompile using O3 level compilation for a whole app using a standard JVM, and not have to worry about the weird and hard-to-debug performance fluctuations that come with JITs.

[pjmlp]

Hotspot can cache generated binary code across runs since Java 11, but people keep using Java 8....

[coldtea]

IntelliJ comes (optionally, but by default) with it's own packaged JRE/JDK/Java version iirc, so that wouldn't be an issue...

[pjmlp]

Apparently they couldn't be bothered to provide an AppCDS archive in modern JVM to go alongside InteliJ.

[coldtea]

I also have the feeling that's only pjmlp and maybe 100 enterprises around the world that do use some features like these!

You always seem to mention them (class sharing, Java AOT compilers, etc), but nobody (for values of somebody < enough) seems to be actually using them :-)

[pjmlp]

When one does enterprise computing those features are available to anyone that cares.

It is not my fault many developers don't care about their tooling, and settle for worse is better. :)

[coldtea]

So, that's my question then: are those features really mature and available for using in production.

Or is it like some half-done features with several caveats and/or some companies with this or that compiler extension (like Java AOT), that might or might not work well, not have good documentation, or any kind of support, and that some cavalier daredevils opt to use?

I mean, I'm not 100% convinced whether it's devs don't caring, or the tools being niche and "use at your own peril", the reason for that lack of adoption.

GraalVM, for example, probably still has some rough edges, and that's an official Oracle tool.

In your experience which are the maturest alternative Java deployment tools/compilers/options?

[krzyk]

AOT can't take into consideration runtime, which might result in less efficient code compilation vs JIT.

So it is apples vs oranges. One is faster here the other there.

GC might be an issue, but for me IDEA feels fast and the added benefit of code navigation vs e.g. vim is worth it.

[darksaints]

But it might also result in less efficient code compilation, because the runtime overhead of some types of optimizations (especially the extremely powerful global optimizations) isn't really feasible while the app is running.

AOT + PGO really is the best of both worlds, but from a devops perspective it gets a bit tricky. But it would be a no-brainer for something like Intellij.

[coldtea]

>AOT can't take into consideration runtime, which might result in less efficient code compilation vs JIT.

That has for decades been a "in the future we'll have flying-cars" style promise for 99% of workloads...

Sure, JIT can theoritically optimize based on runtime hints. But most of the time, for any practical use, it's slower than AOT.

[darksaints]

JITs have been extremely successful for dynamically typed languages, but that has always been a low hanging fruit for optimization.

Once you have a static type system, the JIT doesn't bring you much over ordinary AOT compilation, and no benefit over PGO...while losing out on global optimizations that aren't feasible in a JIT.

[lmilcin]

If that was "the" problem, why would past versions of IDEA be fast?

Java and JVM are very fast. I know, because I used to do cutting edge algorithmic trading in C with premise that Java is slow and then I was asked to rewrite it to Java with the result being only about 10-30% slower. In this case we are talking receiving messages from network, performing complex processing and sending responses (on another connection) within 5-10 microseconds.

And that was a decade ago, my understanding Java only got better in the meantime, but I am working on more mundane backend/reactive systems and don't require really low latency.

[darksaints]

I never once said Java was slow. I was saying that JIT compiling is a bad fit for an IDE. The workloads present in an IDE cause lots of problems for JIT compilers. And those problems actually can be exacerbated by an evolving code base with lots of new features.

[lmilcin]

> The workloads present in an IDE cause lots of problems for JIT compilers

This would suggest the JIT is a problem. But that is not true, the "workload problem" really means "bloat".

Any software is written for the machine it runs on and Java programs are written for JVM. No machine is perfect and writing performant software requires that you understand peculiarities of the architecture you are working on. If you ignore it it is not the problem of the platform, the problem is you.

Now, the trouble with Java software is what I call "OOP bloat", which is basically overloading the runtime with overheads of abstractions.

What is acceptable level of overhead will depend on how much you value your time vs performance of application so it is not categorically declare it is bad. That assuming the overhead is accomplishing something else (like making the code simpler, easier to develop/maintain).

[darksaints]

Yes, the JIT is the problem. And no, this has absolutely nothing to do with OOP or bloated abstractions. Java is a great language, and the Jetbrains IDEs are written extremely well and have very high coding standards. It is all about the JIT. JITs do really well for code with lots of hot loops and few branches, because inlining and loop optimizations are the classic case for needing execution profiles. But IDEs are the opposite of that...there are branches everywhere, and very few hot loops. JITs are the worst possible compilation model for this type of code, because it is constantly going to be optimizing, deoptimizing, and reoptimizing code. The JIT is just constant overhead for something that should just be profiled and compiled one time.