4 ms·

Java programs are slow to start because of all the JVM overheads, but after that the performance is probably between 1x and 2x as slow as C (it depends a lot on

by xiaq 5y ago

Java programs are slow to start because of all the JVM overheads, but after that the performance is probably between 1x and 2x as slow as C (it depends a lot on the workload, of course). Java is definitely not a slow language in general, just has slow startup. The slow startup time is the reason why Java is considered high performance in "enterprise software", but has a reputation of being slow among developers, especially non-Java developers. "Enterprise software" is usually long-running server-side programs, so you barely care about the startup time. But if you're using Java programs as part of your development workflow you'll tend to start and restart them repeatedly and the startup time can get really annoying. Java's GUI libraries also tend to be not very well optimized, which further contributes to people's impression of Java's performance. In the case of this particular project, even though it's a terminal application, since it's a WM you'll likely start it once and leave it running for a pretty long time (as opposed to programs like "ls" which you run again and again), so this is in fact a good place to use Java. You can also use GraalVM to compile Java programs ahead of time these days, and get much faster startup.

capableweb 5y ago
> You can also use GraalVM to compile Java programs ahead of time these days, and get much faster startup. Just wanted to add a note that there is a tradeoff involved, as programs compiled with GraalVM will have worse performance compared to running directly with the JVM, but the startup speed will be faster. For CLIs, GraalVM is a god send. For long-running servers/daemons, JVM is still king.
- pjmlp 5y ago
  For CLIs, AOT compilation has been available since around 2000 for those whose employers could afford commercial JDKs, or try their luck with gcj. Nowadays both OpenJDK and OpenJ9 offer free JIT caches with PGO data, GraalVM isn't the only free beer option.
  - capableweb 5y ago
    > AOT compilation has been available ... commercial JDKs, or try their luck with gcj > OpenJDK and OpenJ9 offer free JIT caches with PGO data As someone who never been exposed to either of those options, what kind of startup times do they offer compared to GraalVM? With GraalVM compiled Native Image I get same startup performance as any random Go program, would those offer the same performance when it comes to startup? Is there any tradeoff regarding long-term performance for daemons and similar?
    - pjmlp 5y ago
      Much better, because you still do have the JIT data, it is similar to having done a couple of GraalVM runs gathering profile data. Here is an overview of using it with Maven https://www.morling.dev/blog/building-class-data-sharing-archives-with-apache-maven/ https://www.morling.dev/blog/building-class-data-sharing-arc... And here is the documentation for the JIT/AOT and JIT server preview for J9, https://www.eclipse.org/openj9/docs https://www.eclipse.org/openj9/docs. By the way, this is also the way that ART evolved after the short lived AOT attempt. Nowadays a modern version of ART will have a tiered execution of fast startup interpreter (when no native code is available), a JIT with PGO data gathering, AOT compilation from only the parts that matter when the device is idle, upload of PGO profiles into the store so that every device of similar class doesn't start from zero when an APK gets installed. If the PGO dataset changes, then it backs into JIT again, and recompiles the native code again on idle.
cle 5y ago
The Java ecosystem has a deeply engrained habit of doing expensive time-consuming things at startup too, like classpath scanning, eager caching and dependency injection, etc. GraalVM has a bunch of tradeoffs…executables can’t be cross-compiled, anything using reflection or other dynamic features are difficult to compile, only a subset of the standard library is (was?) supported, etc. Honestly there are much better languages to use for compiled CLIs these days, I would still steer clear of Java for CLI tools unless you need to reuse existing code. But I do agree with you that Java/JVM is a decent option for a WM, but using GraalVM would ruin all the nice properties of the JVM for that use case (JIT + dynamism).
- pjmlp 5y ago
  With a modern JVM, you can work around that expensive startup by making use of JIT caches.
- KronisLV 5y ago
  You know, it feels like you're right about the technical aspects, but there's an alternate point of view to be considered: maybe, in some circumstances, the dynamic loading and execution of code through reflection and other mechanisms actually is a bad thing? If i got a euro for every time i run into problems at runtime when porting Spring to Spring Boot or Spring Boot 1.X to Spring Boot 2.X projects, i'd have enough money never to have port projects like that over. Whereas without such dynamic logic, if your code compiles, you can be pretty confident that there won't be such oddities, classpath or dependency conflicts, weird scoping rules for Maven (especially with the <provided/> option which means that all of the sudden your app becomes dependent on an app server and its specifics - does your install of Tomcat or TomEE have the correct version of the .jar you want to use, or maybe it'll be missing, or maybe there'll be two libraries loaded at the same time?). Of course, picking a tech stack in which such approaches and dynamism aren't even prevalent is also a good alternative, though not everyone enjoys the more static way of development either.
  - AtlasBarfed 5y ago
    You think java devs have it bad with ecosystem churn? The six months I spent in "modern javascript" was hilariously unstable. Classpath scanning is so unnecessarily hard in the JVM. I get they want flexible classloaders that may not have foreknowledge of the classes they can load, or that may not be simple zip/jars or filesystem-resident class files. But the fact that minority seems to doom classpath scanning to ludicrous workarounds and contortions rather than simply provide a "what classes do I know" api on the classloader that isn't a guarantee seemed ridiculous. The JVM should provide a cached map of the available classes. Jars/zips should optionally be able to provide a list/structure for fast scanning. "Full compilation" can still rely on shared libraries though, correct? Same boat there?
pjmlp 5y ago
For those stuck with Java 8, yes they can be slow to start. For everyone else that has moved on, there are JIT caches and AOT compilers, no longer something only available to consumers from commercial JDKs.

by xiaq 5y ago

capableweb 5y ago

> You can also use GraalVM to compile Java programs ahead of time these days, and get much faster startup. Just wanted to add a note that there is a tradeoff involved, as programs compiled with GraalVM will have worse performance compared to running directly with the JVM, but the startup speed will be faster. For CLIs, GraalVM is a god send. For long-running servers/daemons, JVM is still king.

pjmlp 5y ago
For CLIs, AOT compilation has been available since around 2000 for those whose employers could afford commercial JDKs, or try their luck with gcj. Nowadays both OpenJDK and OpenJ9 offer free JIT caches with PGO data, GraalVM isn't the only free beer option.
- capableweb 5y ago
  > AOT compilation has been available ... commercial JDKs, or try their luck with gcj > OpenJDK and OpenJ9 offer free JIT caches with PGO data As someone who never been exposed to either of those options, what kind of startup times do they offer compared to GraalVM? With GraalVM compiled Native Image I get same startup performance as any random Go program, would those offer the same performance when it comes to startup? Is there any tradeoff regarding long-term performance for daemons and similar?
  - pjmlp 5y ago
    Much better, because you still do have the JIT data, it is similar to having done a couple of GraalVM runs gathering profile data. Here is an overview of using it with Maven https://www.morling.dev/blog/building-class-data-sharing-archives-with-apache-maven/ https://www.morling.dev/blog/building-class-data-sharing-arc... And here is the documentation for the JIT/AOT and JIT server preview for J9, https://www.eclipse.org/openj9/docs https://www.eclipse.org/openj9/docs. By the way, this is also the way that ART evolved after the short lived AOT attempt. Nowadays a modern version of ART will have a tiered execution of fast startup interpreter (when no native code is available), a JIT with PGO data gathering, AOT compilation from only the parts that matter when the device is idle, upload of PGO profiles into the store so that every device of similar class doesn't start from zero when an APK gets installed. If the PGO dataset changes, then it backs into JIT again, and recompiles the native code again on idle.

cle 5y ago

The Java ecosystem has a deeply engrained habit of doing expensive time-consuming things at startup too, like classpath scanning, eager caching and dependency injection, etc. GraalVM has a bunch of tradeoffs…executables can’t be cross-compiled, anything using reflection or other dynamic features are difficult to compile, only a subset of the standard library is (was?) supported, etc. Honestly there are much better languages to use for compiled CLIs these days, I would still steer clear of Java for CLI tools unless you need to reuse existing code. But I do agree with you that Java/JVM is a decent option for a WM, but using GraalVM would ruin all the nice properties of the JVM for that use case (JIT + dynamism).

pjmlp 5y ago
With a modern JVM, you can work around that expensive startup by making use of JIT caches.
KronisLV 5y ago
You know, it feels like you're right about the technical aspects, but there's an alternate point of view to be considered: maybe, in some circumstances, the dynamic loading and execution of code through reflection and other mechanisms actually is a bad thing? If i got a euro for every time i run into problems at runtime when porting Spring to Spring Boot or Spring Boot 1.X to Spring Boot 2.X projects, i'd have enough money never to have port projects like that over. Whereas without such dynamic logic, if your code compiles, you can be pretty confident that there won't be such oddities, classpath or dependency conflicts, weird scoping rules for Maven (especially with the <provided/> option which means that all of the sudden your app becomes dependent on an app server and its specifics - does your install of Tomcat or TomEE have the correct version of the .jar you want to use, or maybe it'll be missing, or maybe there'll be two libraries loaded at the same time?). Of course, picking a tech stack in which such approaches and dynamism aren't even prevalent is also a good alternative, though not everyone enjoys the more static way of development either.
- AtlasBarfed 5y ago
  You think java devs have it bad with ecosystem churn? The six months I spent in "modern javascript" was hilariously unstable. Classpath scanning is so unnecessarily hard in the JVM. I get they want flexible classloaders that may not have foreknowledge of the classes they can load, or that may not be simple zip/jars or filesystem-resident class files. But the fact that minority seems to doom classpath scanning to ludicrous workarounds and contortions rather than simply provide a "what classes do I know" api on the classloader that isn't a guarantee seemed ridiculous. The JVM should provide a cached map of the available classes. Jars/zips should optionally be able to provide a list/structure for fast scanning. "Full compilation" can still rely on shared libraries though, correct? Same boat there?

pjmlp 5y ago

For those stuck with Java 8, yes they can be slow to start. For everyone else that has moved on, there are JIT caches and AOT compilers, no longer something only available to consumers from commercial JDKs.