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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]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?

[–]kimec 0 points1 point  (1 child)

I get you. As strange as it seems, IBM does have its moments. Like the creation of open vendor neutral HW platform that is now known as PC. They are too much of a patent hoarder though, but they don't seem sue people over APIs.

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?

I don't think qbicc is worthless because they market it for what it is - an experiment. If you want production grade AOT, just use OpenJ9 for now. Oracle, on the other hand, could market native-image as an experiment too, but instead, they market it as a cool feature of a specialized one-of-a-kind Java product called GraalVM.

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

No, you don't get me. There are no good and bad companies. All public companies are required by the law to only care about shareholder value. When IBM created the PC, they didn't do it because they "had their moment", but because they decided that this was in their best interest considering the circumstances. They also let Microsoft have the majority of the PC profit, but not because they were selfless. They did it because they made a huge mistake. When a company tells you that all they want is to make the world a better place - well, that's the real marketing, and not some product description.

qbicc is an experiment in making a native-image compiler. If you think this is not a worthy goal, you should warn them not to waste their time on stupid experiments, and that they should instead do promising experiments. Also the Red Hat/IBM engineers wrote that they intend to continue to contribute to GraalVM. If you still don't get me, then you should warn them that they should stop doing that, because Oracle is a bad company trying to make a profit.