3 ms·

> this is a huge downside. Also the compiler can only do static analysis and code generation. I'd much rather a hotspot VM analyze the running code and identify

> this is a huge downside. Also the compiler can only do static analysis and code generation. I'd much rather a hotspot VM analyze the running code and identify the optimizations on the fly.

Yasuraka 2y ago
>I'd much rather a hotspot VM analyze the running code wasting gigabytes of ram and fast startup times >and identify the optimizations on the fly and still get gapped by statically compiled languages. I guess these are a cheap price to pay for the benefit of ... having to install and patch runtimes.
- forty 2y ago
  > still get gapped by statically compiled languages. Which statically complicated languages are you referring to? :)
- pragmatick 2y ago
  Native Image requires so much more work to have a medium-sized java project properly run when compiled the price gets a lot higher.
  - sgammon 2y ago
    More of this configuration is automatic with every release
- gf000 2y ago
  Unused RAM is wasted. If you have plenty available then doing useless memory releases (including dropping/destroying objects with RAII, which can end up doing a lot of work in case of a data structure containing other objects that have to be dropped) will just hurt your throughput. Nonetheless, Java has a pretty trivial single flag to set an appropriate heap size if you are not happy with the default. -- You are thinking of AOT compiled, but does that AOT language support arbitrary class loading to expand functionality, live observability while taking almost zero overhead for that? -- So what do you do if a statically linked library of yours has a vulnerability?
- roncesvalles 2y ago
  There are instances where JVM's dynamically optimized code runs faster than equivalent C code compiled to a native binary. The Hotspot JVM is no joke.
  - sgammon 2y ago
    It's not either/or. Compiling a Native Image binary gives you the JIT power of the JVM, but with faster warmup time. Peak-peak performance is not as good as JVM in many cases, but how long does your process actually spend within that space? Native Image can be optimal for many cases
tannhaeuser 2y ago
What's your point? This is what the regular JVM/HotSpot has been doing for ages (and GraalVM, too). Whereas native-image does AOT, with optional profile-guided optimization to identify hotspots on the fly.
- cratermoon 2y ago
  Apparently I left out a line break. It should read > this is a huge downside. The compiler can only do static analysis and code generation. I'd much rather a hotspot VM analyze the running code and identify the optimizations on the fly. So I believe we're in agreement, that AOT imposes does limited optimizations compared to HotSpot JIT

> this is a huge downside. Also the compiler can only do static analysis and code generation. I'd much rather a hotspot VM analyze the running code and identify the optimizations on the fly.

Yasuraka 2y ago

>I'd much rather a hotspot VM analyze the running code wasting gigabytes of ram and fast startup times >and identify the optimizations on the fly and still get gapped by statically compiled languages. I guess these are a cheap price to pay for the benefit of ... having to install and patch runtimes.

forty 2y ago
> still get gapped by statically compiled languages. Which statically complicated languages are you referring to? :)
pragmatick 2y ago
Native Image requires so much more work to have a medium-sized java project properly run when compiled the price gets a lot higher.
- sgammon 2y ago
  More of this configuration is automatic with every release
gf000 2y ago
Unused RAM is wasted. If you have plenty available then doing useless memory releases (including dropping/destroying objects with RAII, which can end up doing a lot of work in case of a data structure containing other objects that have to be dropped) will just hurt your throughput. Nonetheless, Java has a pretty trivial single flag to set an appropriate heap size if you are not happy with the default. -- You are thinking of AOT compiled, but does that AOT language support arbitrary class loading to expand functionality, live observability while taking almost zero overhead for that? -- So what do you do if a statically linked library of yours has a vulnerability?
roncesvalles 2y ago
There are instances where JVM's dynamically optimized code runs faster than equivalent C code compiled to a native binary. The Hotspot JVM is no joke.
- sgammon 2y ago
  It's not either/or. Compiling a Native Image binary gives you the JIT power of the JVM, but with faster warmup time. Peak-peak performance is not as good as JVM in many cases, but how long does your process actually spend within that space? Native Image can be optimal for many cases

tannhaeuser 2y ago

What's your point? This is what the regular JVM/HotSpot has been doing for ages (and GraalVM, too). Whereas native-image does AOT, with optional profile-guided optimization to identify hotspots on the fly.

cratermoon 2y ago
Apparently I left out a line break. It should read > this is a huge downside. The compiler can only do static analysis and code generation. I'd much rather a hotspot VM analyze the running code and identify the optimizations on the fly. So I believe we're in agreement, that AOT imposes does limited optimizations compared to HotSpot JIT