Oracle Releases GraalVM 22.0 With New Features

[tuxd3v]

The native image part compiles to native code. But it's not inside GraalVM, it's been made into an optional module years ago.

Ok, thanks, but... its possible to compile entire project to native code, or only Shared Libraries?

[nadirx]

Ok, thanks, but... its possible to compile entire project to native code, or only Shared Libraries?

By default it compiles to a native executable. You can compile to shared library if you want.

[barti_ddu]

I would highly recommend using a real world application instead of hello world. Noone is realistically distributing hello world as a native image, so optimizing for that would be pointless. It would be much more interesting to test it with a more complex application.

Hhh.. I agree here (and already mentioned that), however I was considering (very preliminary) graalvm with native image for a set of (relatively) small cli applications with minimal external dependencies (no reflection, jni, etc.), thus 5.8M increase in binary size is quite substantial for me.

I'll look if this increase is due to some additional classes being compiled-in by default and just exclude them, however, I was hoping that

Native Image updates to reduce the image size

means just that, literally

[bug77]

I would highly recommend using a real world application instead of hello world. Noone is realistically distributing hello world as a native image, so optimizing for that would be pointless. It would be much more interesting to test it with a more complex application.

No one distributes hello world, but how much confidence should I invest in something that fails to handle the most basic task properly? Which optimization can be applied to a large project, but not to hello world?

And yes, I have tried it recently on a more realistic, but still simple, web service. I still ended up with something over 200MB in size

[RahulSundaram]

No one distributes hello world, but how much confidence should I invest in something that fails to handle the most basic task properly? Which optimization can be applied to a large project, but not to hello world?

And yes, I have tried it recently on a more realistic, but still simple, web service. I still ended up with something over 200MB in size

It's actually not realistic to extrapolate from hello world because otherwise tiny programs is sort of the worst case for anything that bundles a runtime. Plenty of optimizations can apply to large programs but be neutral or negatively affect smaller programs.

The question is not whether it would increase size, it obviously would, the question is whether for a realistic web service, the latest version does better ie) the size reduces compared to the versions before.

[krzyzowiec]

Gating optimizations behind the enterprise edition is understandable, but leaves a bad taste in the mouth.

It’s a very neat project, but I am more into Rust for low level, high performance code. I just wrote a small thing with it and I am super impressed with the language. The compiler is lovely and helpful! Maybe if I were part of a team using multiple languages, I think GraalVM would be more intriguing.

Or maybe if I just really wanted to write Clojure for a microservice…

[bug77]

It's actually not realistic to extrapolate from hello world because otherwise tiny programs is sort of the worst case for anything that bundles a runtime. Plenty of optimizations can apply to large programs but be neutral or negatively affect smaller programs.

The question is not whether it would increase size, it obviously would, the question is whether for a realistic web service, the latest version does better ie) the size reduces compared to the versions before.

I would love to test that, but the project in its current state doesn't compile to native anymore. Something about file descriptors and running threads already existing in the image heap, nothing actionable.

[bug77]

Gating optimizations behind the enterprise edition is understandable, but leaves a bad taste in the mouth.

It’s a very neat project, but I am more into Rust for low level, high performance code. I just wrote a small thing with it and I am super impressed with the language. The compiler is lovely and helpful! Maybe if I were part of a team using multiple languages, I think GraalVM would be more intriguing.

Or maybe if I just really wanted to write Clojure for a microservice…

+1 for Rust. I haven't touched C or C++ for more than a decade, but when I tried Rust, I was surprisingly productive. Ugly syntax, but cargo and good documentation more than make up for that.

As for GraalVM, I follow it because it's intriguing from an engineering standpoint. But it's really a solution looking for a problem - not once have I seen a client hindered because they couldn't run Java, R and Ruby on the same VM. The only real world problem it could solve is taking something compiled to IR code and with a big runtime and translate it to proper code. But it can't do that, that feature is experimental with no clear (or approximate) roadmap.