2 ms·

> 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 i

> 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.

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.