Hacker News Reader

Comment by cratermoon | Hacker News Reader

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

View on HN

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

> still get gapped by statically compiled languages.

Which statically complicated languages are you referring to? :)

Native Image requires so much more work to have a medium-sized java project properly run when compiled the price gets a lot higher.

More of this configuration is automatic with every release

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?

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.

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

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.

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

Reply on news.ycombinator.com