7 ms·

When did JVM switch to the insanely fast HotSpot JIT?

acdha 5y ago
Later, but HotSpot to this day means “less slow” - it’s a lot better than it used to be but you still need considerably more RAM and CPU than native apps.
- bayindirh 5y ago
  I don't think the need is that larger when compared to today's applications, esp. Electron based applications. Eclipse still uses less resources than VSCode/Atom while juggling more balls at the same time.
  - oriolid 5y ago
    Just because someone managed to come up with a worse alternative doesn't make Java good. The main problems, initial JIT time and fixed heap size still remain.
    - jpgvm 5y ago
      Java has always been tunable to be more aggressive at returning memory to the OS if you are worried about the resident memory size. Newer versions of Java with the more advanced GCs are even better at it. Ultimately Java's runtime performance wasn't really to blame for it's lack of success but rather the awkwardness of JRE distribution, garbage applet sidetrack and lack of high quality GUI toolkits that actually felt native rather than attempting to do "platform independent look and feel".
      - oriolid 5y ago
        How does the tuning work? To me it still seems that JVM (or at least the version bundled with JetBrains IDEs) keeps allocating memory until it's near max heap size and it's up to the user to find the value that's large enough stop the app getting stuck doing full GC but leaves memory for other apps.
        bayindirh 5y ago
        JVM can be tuned via the command line during startup. Eclipse comes with 512MB as the heap size, and you can enable a small gauge to see how it's doing. I've never seen "This heap is small, please give me more space" error from Eclipse. Also, latest versions of Java (starting with 16 IIRC) doesn't grind to halt during large GC passes. I've developed enough applications in Eclipse during past 20 years, and it has become from being an absolute lead ball to something agile for its size, both in macOS and Linux. I've found an infinite loop bug in CDT, and only with that I was able to make JVM throw the towel, and call it quits. JVM is very smart and resilient in memory management, I've seen some stuff during my life.
        jjoonathan 5y ago
        Defaults are important. The world runs on defaults. Bad defaults cause real problems and take real work to fix, so it's fair to blame software for poor out-of-the-box behavior, even if it can be configured away.
        oriolid 5y ago
        Well, a message saying "This heap is small, please give me more space" would be all too helpful. I haven't touched Eclipse in years, but Clion and Rider have this failure mode where they just use all the CPU all the time and it's up to user to figure out that it's GC and how to increase the heap size. I was hoping for an option that would mean "use all the memory you need but don't keep the maximum allocated just in case". The current -Xmx seems to be more like "postpone full GC until the maximum has been reached". I'm not sure if it's significant that Jetbrains IDEs and Eclipse are separate products. Google can't distinguish between different Jetbrains products in search results, maybe Eclipse can be lumped into same group by some logic.
        KptMarchewa 5y ago
        Jetbrains IDEs have this "heap is too small" message though.
        5y ago
  - acdha 5y ago
    Atom, yes, VSCode, no. The latter is noticeably faster and uses less RAM — and the JetBrains suite is even worse. A large part of this is cultural. The Java world has been prone to high complexity styles which are hard to optimize and there doesn’t appear to be much social expectation that you profile or improve code until you max out what you can easily fit on a single system.
    - kaba0 5y ago
      Jetbrains’ IDEs do more things by an order of magnitude than a vscode full-of-plugins, so it is not a fair comparison.
      - acdha 5y ago
        Far less than an order of magnitude — and it shouldn’t be the case that every advanced feature slows down core functionality like how long it takes for a key press to render when you’re not even using that feature. They have lots of functionality but proponents have always noted the … stately … speed and these days the ones I know have moved to VSC because it’s competitive for the features they use and they benefit from better performance all of the time.
        kaba0 5y ago
        You still can’t really conclude that it is due to Java somehow. Also, if jetbrains would finally use a non-deprecated GC and a slightly more GC-friendly max heap setting, intellij would have much better latency. (You can try this out yourselves, just go with G1GC and increase heap size for a good improvement. But the best experience would come from ZGC but it is only available in a newer runtime than the bundled 11)
        acdha 5y ago
        Definitely, but when almost every Java program I use has issues with performance and memory it suggests that the culture doesn’t value those things highly enough. The same is often true in the JavaScript world, which makes VSC interesting because it’s famously an outlier in the Electron world.
- zmmmmm 5y ago
  This is only partly true. HotSpot is pretty amazing performance wise. For certain code patterns it really does produce assembly competitive and even better than what you get from the equivalent vanilla C++ solution. The issues are (a) it only kicks in once something gets profiled quite a few times (so your first encounters with a function - the one you base your impressions of usually, are at its worst), (b) the overhead of JIT weighs down the machine further at exactly the moment (a) is occurring. And then (c) there are quite a lot of code patterns and in particular architectural styles encouraged by the Java ecosystem that are hostile to this whole process. I do wonder why Java has not gone the python direction of caching the JIT output in binary form so at least the 2nd time you launch an app it doesn't need to be redone every time.
  - kaba0 5y ago
    It did actually work for a time that you could point the jvm to precompiled class files, but it got discontinued (it was part of GraalVM which has a different pace to OpenJDK) But imo that is only relevant for startup - otherwise the problem with Java’s JIT compilation is the identity of objects, which makes it much harder to do some optimizations. Hopefully with valhalla we will see quite a boost.
  - native_samples 5y ago
    It's complicated to do binary caching for various low level reasons. Amongst other things, the generated binary code is specific to the precise location in memory and makes lots of assumptions about the state of the runtime like what classes have been been initialized. Still, HotSpot has been slowly (too slowly) getting AOT-like optimizations in the form of AppCDS. It doesn't actually store compiled code but a lot of other internal data structures can be stored to disk in native form and just mmapped at startup. It's usually a 30% win or so, which isn't bad.
dtech 5y ago
HotSpot took 2 decades to get to its current performance, and while its JITted performance is good, for desktop apps cold boot performance is at least as important.
- jjoonathan 5y ago
  Moore's law didn't hurt either. I think there's a big confounding factor, though: people self-select into platforms depending on what they care about. People who self-selected into Java didn't value perf. They were then inclined to ignore their own performance problems for the same reason they selected Java: they didn't value perf. That's why so many Java GUIs chug so hard, even today, when it really can't be blamed on Java itself. For instance, Ghidra: if you leave a filter active in a GUI box and run an analysis tool, sometimes the runtime of the tool explodes from minutes to days because it refreshes the GUI after each of the zillion model tweaks the analysis tool needs to perform. It's not Java's fault that nobody put in the code to throttle GUI updates, but the same list of priorities that led the creators to choose Java also led them to ignore a massive perf landmine sitting in the middle of the road for all to see and occasionally hit. I recently fired up LibreOffice Sheets to see how it compared to Google Sheets. It took four entire seconds to switch to editing mode in a cell. Every time, not just the first. If I were to root cause the issue, I'm sure it wouldn't be Java's fault -- but I bet that the same priorities that led the project to choose Java led them to ignore a four second stall in their most critical user interaction path. Both of these projects are free, so I'm not upset about getting what I paid for, but I have plenty examples from corporate Java GUIs as well. I don't think this is a Java problem, I think it's a priorities-held-by-Java-programmers problem.
  - lawl 5y ago
    Reminds me of this post: https://nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html?m=1 https://nibblestew.blogspot.com/2020/03/its-not-what-program... In the case of java though in my opinion the problems start at the std library that sometimes forces you to write really inefficient code, or reimplement everything yourself.
  - zmmmmm 5y ago
raverbashing 5y ago
The JVM can be as fast as you want, Swing would make your app drag along

Later, but HotSpot to this day means “less slow” - it’s a lot better than it used to be but you still need considerably more RAM and CPU than native apps.

bayindirh 5y ago
I don't think the need is that larger when compared to today's applications, esp. Electron based applications. Eclipse still uses less resources than VSCode/Atom while juggling more balls at the same time.
- oriolid 5y ago
  Just because someone managed to come up with a worse alternative doesn't make Java good. The main problems, initial JIT time and fixed heap size still remain.
  - jpgvm 5y ago
    Java has always been tunable to be more aggressive at returning memory to the OS if you are worried about the resident memory size. Newer versions of Java with the more advanced GCs are even better at it. Ultimately Java's runtime performance wasn't really to blame for it's lack of success but rather the awkwardness of JRE distribution, garbage applet sidetrack and lack of high quality GUI toolkits that actually felt native rather than attempting to do "platform independent look and feel".
    - oriolid 5y ago
      How does the tuning work? To me it still seems that JVM (or at least the version bundled with JetBrains IDEs) keeps allocating memory until it's near max heap size and it's up to the user to find the value that's large enough stop the app getting stuck doing full GC but leaves memory for other apps.
      - bayindirh 5y ago
        JVM can be tuned via the command line during startup. Eclipse comes with 512MB as the heap size, and you can enable a small gauge to see how it's doing. I've never seen "This heap is small, please give me more space" error from Eclipse. Also, latest versions of Java (starting with 16 IIRC) doesn't grind to halt during large GC passes. I've developed enough applications in Eclipse during past 20 years, and it has become from being an absolute lead ball to something agile for its size, both in macOS and Linux. I've found an infinite loop bug in CDT, and only with that I was able to make JVM throw the towel, and call it quits. JVM is very smart and resilient in memory management, I've seen some stuff during my life.
        jjoonathan 5y ago
        Defaults are important. The world runs on defaults. Bad defaults cause real problems and take real work to fix, so it's fair to blame software for poor out-of-the-box behavior, even if it can be configured away.
        oriolid 5y ago
        Well, a message saying "This heap is small, please give me more space" would be all too helpful. I haven't touched Eclipse in years, but Clion and Rider have this failure mode where they just use all the CPU all the time and it's up to user to figure out that it's GC and how to increase the heap size. I was hoping for an option that would mean "use all the memory you need but don't keep the maximum allocated just in case". The current -Xmx seems to be more like "postpone full GC until the maximum has been reached". I'm not sure if it's significant that Jetbrains IDEs and Eclipse are separate products. Google can't distinguish between different Jetbrains products in search results, maybe Eclipse can be lumped into same group by some logic.
        KptMarchewa 5y ago
        Jetbrains IDEs have this "heap is too small" message though.
        5y ago
- acdha 5y ago
  Atom, yes, VSCode, no. The latter is noticeably faster and uses less RAM — and the JetBrains suite is even worse. A large part of this is cultural. The Java world has been prone to high complexity styles which are hard to optimize and there doesn’t appear to be much social expectation that you profile or improve code until you max out what you can easily fit on a single system.
  - kaba0 5y ago
    Jetbrains’ IDEs do more things by an order of magnitude than a vscode full-of-plugins, so it is not a fair comparison.
    - acdha 5y ago
      Far less than an order of magnitude — and it shouldn’t be the case that every advanced feature slows down core functionality like how long it takes for a key press to render when you’re not even using that feature. They have lots of functionality but proponents have always noted the … stately … speed and these days the ones I know have moved to VSC because it’s competitive for the features they use and they benefit from better performance all of the time.
      - kaba0 5y ago
        You still can’t really conclude that it is due to Java somehow. Also, if jetbrains would finally use a non-deprecated GC and a slightly more GC-friendly max heap setting, intellij would have much better latency. (You can try this out yourselves, just go with G1GC and increase heap size for a good improvement. But the best experience would come from ZGC but it is only available in a newer runtime than the bundled 11)
        acdha 5y ago
        Definitely, but when almost every Java program I use has issues with performance and memory it suggests that the culture doesn’t value those things highly enough. The same is often true in the JavaScript world, which makes VSC interesting because it’s famously an outlier in the Electron world.
zmmmmm 5y ago
This is only partly true. HotSpot is pretty amazing performance wise. For certain code patterns it really does produce assembly competitive and even better than what you get from the equivalent vanilla C++ solution. The issues are (a) it only kicks in once something gets profiled quite a few times (so your first encounters with a function - the one you base your impressions of usually, are at its worst), (b) the overhead of JIT weighs down the machine further at exactly the moment (a) is occurring. And then (c) there are quite a lot of code patterns and in particular architectural styles encouraged by the Java ecosystem that are hostile to this whole process. I do wonder why Java has not gone the python direction of caching the JIT output in binary form so at least the 2nd time you launch an app it doesn't need to be redone every time.
- kaba0 5y ago
  It did actually work for a time that you could point the jvm to precompiled class files, but it got discontinued (it was part of GraalVM which has a different pace to OpenJDK) But imo that is only relevant for startup - otherwise the problem with Java’s JIT compilation is the identity of objects, which makes it much harder to do some optimizations. Hopefully with valhalla we will see quite a boost.
- native_samples 5y ago
  It's complicated to do binary caching for various low level reasons. Amongst other things, the generated binary code is specific to the precise location in memory and makes lots of assumptions about the state of the runtime like what classes have been been initialized. Still, HotSpot has been slowly (too slowly) getting AOT-like optimizations in the form of AppCDS. It doesn't actually store compiled code but a lot of other internal data structures can be stored to disk in native form and just mmapped at startup. It's usually a 30% win or so, which isn't bad.

dtech 5y ago

HotSpot took 2 decades to get to its current performance, and while its JITted performance is good, for desktop apps cold boot performance is at least as important.

jjoonathan 5y ago
Moore's law didn't hurt either. I think there's a big confounding factor, though: people self-select into platforms depending on what they care about. People who self-selected into Java didn't value perf. They were then inclined to ignore their own performance problems for the same reason they selected Java: they didn't value perf. That's why so many Java GUIs chug so hard, even today, when it really can't be blamed on Java itself. For instance, Ghidra: if you leave a filter active in a GUI box and run an analysis tool, sometimes the runtime of the tool explodes from minutes to days because it refreshes the GUI after each of the zillion model tweaks the analysis tool needs to perform. It's not Java's fault that nobody put in the code to throttle GUI updates, but the same list of priorities that led the creators to choose Java also led them to ignore a massive perf landmine sitting in the middle of the road for all to see and occasionally hit. I recently fired up LibreOffice Sheets to see how it compared to Google Sheets. It took four entire seconds to switch to editing mode in a cell. Every time, not just the first. If I were to root cause the issue, I'm sure it wouldn't be Java's fault -- but I bet that the same priorities that led the project to choose Java led them to ignore a four second stall in their most critical user interaction path. Both of these projects are free, so I'm not upset about getting what I paid for, but I have plenty examples from corporate Java GUIs as well. I don't think this is a Java problem, I think it's a priorities-held-by-Java-programmers problem.
- lawl 5y ago
  Reminds me of this post: https://nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html?m=1 https://nibblestew.blogspot.com/2020/03/its-not-what-program... In the case of java though in my opinion the problems start at the std library that sometimes forces you to write really inefficient code, or reimplement everything yourself.
- zmmmmm 5y ago

raverbashing 5y ago

The JVM can be as fast as you want, Swing would make your app drag along