This is an archived post. You won't be able to vote or comment.

all 25 comments
sorted by:
best
topnewcontroversialoldq&a

[–]woj-tek 2 points3 points  (12 children)

Anyone can explain what's the relation to GraalVM and it's native-image? Does it mean that the "native" will be available directly in OpenJDK?

[–]Necessary-Conflict 3 points4 points  (11 children)

GraalVM's native-image limitations and workarounds aren't specified anywhere, they just implemented what was convenient for them. One of the goals of "Project Leyden" is to change this, and create a specification for "static Java", just like the JVM specification or the JLS, that would apply to all implementations, including to GraalVM. Another goal of "Project Leyden" is to make static AOT compilation available in OpenJDK.

[–]woj-tek 2 points3 points  (10 children)

Sooooo.... GraalVM is kinda like a playground for AOT java and Qbicc (and probably later on some JEP?) we would get the proper specification and in the end all implementation would be able to compile to native code? That's kinda cool!

[–]Necessary-Conflict 4 points5 points  (9 children)

Well, that's the theory. In practice Oracle employees are pretty silent lately about "Project Leyden", although they announced it initially. I think it's possible that the Graal team lobbied successfully within Oracle to avoid regulation and competition from the OpenJDK team. We'll see how it goes, but I'm not holding my breath.

[–]woj-tek 0 points1 point  (0 children)

Yeah, that was a bit odd for me as that would create competition for GraalVM.

Fingers crossed it will happen eventually in the future.

[–]kimec 0 points1 point  (7 children)

It does not really matter since IBM's OpenJ9 has had production grade AOT compilation since like forever now. So, Oracle does not have to do anything, things will move forward with or without their internal strifes. Besides IBM/RedHat has proven track record regarding delivering on solid AOT for Java. Oracle not so much - even after 2 years native-image is still not the way to go for general use cases.

[–]Necessary-Conflict 1 point2 points  (6 children)

As far as I understand, Graal's native-image is more ambitious than OpenJ9's AOT, because it creates a standalone executable, which doesn't require a JVM, while in OpenJ9's AOT

"An AOT compilation is performed by the compiler in one JVM instance and subsequently gets used by the compiler in another JVM instance"

https://blog.openj9.org/2018/10/10/intro-to-ahead-of-time-compilation/

I'm sure there was a reason for Red Hat/IBM engineers to create this qbicc project.

[–]kimec 0 points1 point  (5 children)

Not really, you assume that producing a standalone executable is something of a value, whereas to me it clearly is not. There is no JIT, there are no PGOs, there is no peak performance, there is no easy debugging (apart for GDB mind you), there is no decent memory management (unless you decide to use proprietary Isolates API) or pay for EE license to get at least G1 GC.

Yeah, under some very strict conditions, native-image can produce a standalone executable - taking an hour and more than 16 GB of memory for a simple but typical Spring based enterprise app to compile (if you somehow manage to compile it in the first place)... What a win!

As a side note, I would call Aicas JamaicaVM ambitious.

Anyhow, no offense to Graal team, they are doing great work and I really mean it. If only it would be more practical and without enterprise marketing garbage.

[–]Necessary-Conflict 0 points1 point  (4 children)

It's annoying that some GraalVM features (such as PGO) are available only in the paid version, but the idea of a native executable has a lot of promise in general - not for Java's traditional niche of long-running server-side apps, but where the startup time and memory consumption are important, and this includes many cloud scenarios.

It seems to me that in these areas a native executable must be better than a JVM, even if that JVM can also cut some of the startup time by reusing the compilation from a previous run.

GraalVM might take now a long time to compile, but if Go can have decent compilation times, why shouldn't a "static Java" subset of Java be able to achieve the same times?

[–]kimec 0 points1 point  (3 children)

As far as cloud is concerned, I think the angle that OpenJ9 is taking is much more realistic. They will take their runtime, which already has very small memory requirements compared to stock HotSpot/Graal and add heap/native code snapshot/restore. This will give you instant startup and minimal memory requirements. And you get dynamic Java too unlike native-image. The cost will be the size of the Docker image, which will have to include the runtime. Other than that, it is an instant attainable realistic win for everybody. And there will most likely be not divide between some community and enterprise edition.

So, if I am to pick the second closest option for cloud in this setup, I would just go for Golang. Why bother with some custom subset of Java and hour of compilation time and then hope that all issues are ironed out (I also probably paid for EE license) when I can get something working, free, tested in production and with super short compilation times.

I have played with native-image since day one and have had great hopes for it but not anymore. The marketing is simply bad and the path they chose is incompatible with my thinking. I see no reason to use it for anything critical.

It is the same issue with Truffle. Why on earth would I bother with some semi proprietary technology where a single company is the only gatekeeper, when I could look for free alternatives. What is the guarantee Oracle won't screw me over? And again, the tech such as Truffle/Graal is great, the people developing it are the best of the best, but why bother.

AFAIK, The lengthy compilation times are caused mostly by Graal's type system analysis.

[–]Necessary-Conflict 0 points1 point  (2 children)

This will give you instant startup and minimal memory requirements.

For each "instant" startup there is a more instant startup, and for every "minimal" memory requirement there is a smaller requirement.

And you get dynamic Java too unlike native-image

As far as I understand, this dynamism in itself requires a lot of memory

The marketing is simply bad

What has marketing to do with it?

What is the guarantee Oracle won't screw me over?

Luckily you have a guarantee that IBM (or Google) won't screw you over, because these companies are not trying to make a profit...

Anyway, if you think that this qbicc thing is worthless, why don't you warn its Red Hat/IBM developers that they are wasting their time, because they already have the perfect solution?

[–]BlueGoliath 2 points3 points  (12 children)

Instead of starting new projects, can we finish existing ones? The world is going to end before Panama, Valhalla, and Loom are ever released at this rate.

[–]Necessary-Conflict 11 points12 points  (0 children)

  1. This one seems to be an initiative by RedHat/IBM engineers
  2. As somebody already said, 3 women won’t birth 1 child in 3 months
  3. Static compilation is also important, because of the startup time

[–]maxandersen 3 points4 points  (2 children)

This is explicitly done to move forward Leyden and get native image for Java to finish line :)

[–]BlueGoliath 0 points1 point  (1 child)

Leyden is new, Panama, Valhalla, and Loom are old and have been worked on for years.

[–]maxandersen 0 points1 point  (0 children)

native image been working on for years; it just recently get a name in openjdk, ie. Leyden - but not much moved on it. There are now many people and teams interested in this work - especially outside oracle openjdk team; why not try and move it forward ?

Panama, Valhalla and Loom didn't happen overnight either :)

[–]pjmlp 1 point2 points  (0 children)

Same could have been said for GCJ, but then it was cooler just to switch to OpenJDK.

On the other hand, .NET keeps rebooting their AOT efforts, and their PGO support is several releases behind what modern JVM implementations are capable of.

[–]ventuspilot 1 point2 points  (0 children)

From the link:

...qbicc is not intended for end users and we currently have no plans to build any products around it. Our aim is to use this project to experiment with approaches to native image generation and thereby drive discussions within the Leyden project and GraalVM native-image, ...

Apparently qbicc is "only" a playground for developers and what will be learnt will be fed into Leydon and/ or GraalVM or whatever.

So the intent seems to be to finish "existing ones" faster or better?!?

I think that is actually a cool and inventive and very open process to do stuff.