6 ms·

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

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 6y ago
Hotspot can cache generated binary code across runs since Java 11, but people keep using Java 8....
- coldtea 6y ago
  IntelliJ comes (optionally, but by default) with it's own packaged JRE/JDK/Java version iirc, so that wouldn't be an issue...
  - pjmlp 6y ago
    Apparently they couldn't be bothered to provide an AppCDS archive in modern JVM to go alongside InteliJ.
    - coldtea 6y ago
      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 6y ago
        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 6y ago
        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?
        pjmlp 6y ago
        GraalVM is mature enough to power Twitter. AOT compilers for Java exist in production since around 2000, basically all commercial JVMs supported it, specifically those targeted for embedded deployment. AppCDS in Hotspot is nothing new, basically just like Flight Recorder, proven components from BEA J/Rockit JVM acquired by Oracle, which they eventually decided to make available on Hotspot. Likewise OpenJ9 AOT and JIT caches, have years of production testing, from IBM J9 deployments in WebSphere Realtime JVM (now discontinued), IBM mainframes, Aix and Linux. PTC and Sonic have been used for years in military deployments, and factory automation scenarios. Aicas focus mainly in embedded scenarios. Excelsior JET was quite good, but for whatever reason they went bankrupt. Android Runtime, although not Java, has been AOTing since Android 5, starting with Android 7 evolved into a mix of interpreted/JIT/AOT with PGO from JIT, in Android 10 gained the ability to upload PGO profiles to the store so that devices can AOT right away.
krzyk 6y ago
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 6y ago
  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 6y ago
  >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 6y ago
    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 6y ago
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 6y ago
  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 6y ago
    > 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 6y ago
      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.

pjmlp 6y ago

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

coldtea 6y ago
IntelliJ comes (optionally, but by default) with it's own packaged JRE/JDK/Java version iirc, so that wouldn't be an issue...
- pjmlp 6y ago
  Apparently they couldn't be bothered to provide an AppCDS archive in modern JVM to go alongside InteliJ.
  - coldtea 6y ago
    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 6y ago
      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 6y ago
        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?
        pjmlp 6y ago
        GraalVM is mature enough to power Twitter. AOT compilers for Java exist in production since around 2000, basically all commercial JVMs supported it, specifically those targeted for embedded deployment. AppCDS in Hotspot is nothing new, basically just like Flight Recorder, proven components from BEA J/Rockit JVM acquired by Oracle, which they eventually decided to make available on Hotspot. Likewise OpenJ9 AOT and JIT caches, have years of production testing, from IBM J9 deployments in WebSphere Realtime JVM (now discontinued), IBM mainframes, Aix and Linux. PTC and Sonic have been used for years in military deployments, and factory automation scenarios. Aicas focus mainly in embedded scenarios. Excelsior JET was quite good, but for whatever reason they went bankrupt. Android Runtime, although not Java, has been AOTing since Android 5, starting with Android 7 evolved into a mix of interpreted/JIT/AOT with PGO from JIT, in Android 10 gained the ability to upload PGO profiles to the store so that devices can AOT right away.

krzyk 6y ago

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 6y ago
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 6y ago
>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 6y ago
  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 6y ago

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 6y ago
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 6y ago
  > 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 6y ago
    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.