And is that with their javac or is it reserved only for their native image generation?

In my experience, native image is noticeably slower than regular openjdk, at least for Scala. The start up speed is nice, though.

You need to pay Oracle $lots for a GraalVM enterprise licence to get profile guided optimisations, if you want some of your peak performance back.

Twitter thinks otherwise, as they are the major consumer of GraalVM in production.

GraalVM is a JIT compiler for the most part. That's the one Twitter uses I believe. SubstrateVM is what lets you perform a closed world assumption ahead of time build. And that does indeed run left performant most of the time, but it uses less memory and starts faster.

Unless one feeds it with PGO data, just like it happens in most AOT workflows for optimizations like devirtualization.

What part of production, do you know? Because mobile.twitter.com links are slow as hell to load

Twitter has a couple of talks about it.

https://jaxenter.com/graalvm-chris-thalinger-interview-16307...

> This lets it greatly outperform the JVM, at the expense of some rarely used functionality.

Outperform in what metric? Startup time? Granted. Anything else? Not so much.

>Basically, it’s like switching from the JIT to a C compiler’s -O3.

Yeah and that would be pretty bad (it's not a good analogy to begin with). "-O3" doesn't have anything that a JIT couldn't have. The only advantage is again, startup time. JIT compilation has otherwise only advantages over static compilcation, especially in highly polymorphic code, such as java. Static compilation for polymorphic code is a joke in terms of performance... And every C++ programmer should know that.

I didn't look at the spec, but I would assume that AOT is only the bootup and then the JIT will take over anyway. This means, they'd do some basic precompilation for fat bootup and then use JIT again to optimize the code further based on runtime analysis. Everything else would be a ridicolous step backwards in time and make AOT completely useless, except for some niche scenarios.

As far as I know, Truffle is able to do some absolutely incredible compile-time optimizations —- reaching deeply into what we would normally regard as strictly semantic territory.

(For an example, see some of the optimizations done by TruffleRuby for things like `myArray.sort.first` - which it apparently optimizes by terminating the sort as soon as the first element is sorted to the front of the array... and all that without any special hints in the standard library. Please correct me if I’m wrong... it’s been a few years since I’ve read in depth about TruffleRuby. And granted this example isn’t Java, but I imagine there are great parallels there.)

I'm not sure how it would terminate sort early, my initial assumption was that for small arrays there might be special-casing?

this seems to be a related thread on twitter:

https://twitter.com/ChrisGSeaton/status/1001582169578524672

Are you unsure about the runtime considerations or how the compiler would infer the necessary optimizations?

Can the storage of generic containers change as well? For example, store the objects in the container instead of reference?

> Startup time? Granted. Anything else? Not so much.

Startup time matters a lot especially for Java applications. The reason Java never got to the desktop (including browser) I believe was the startup time.

Startup time matters a lot also for micro-services.

A 2nd great benefit of GraalVM I think is it makes it easy to integrate programs written in different languages, say Node.js and Java for instance.

> Java never got to the desktop (including browser)

What do you mean by this? There are a lot of desktop Java applications...

I'd like to hear about them, because apart from enterprise applications, there aren't that many left. Electron is the new desktop Java.

I wouldn't call them dominant by any stretch, but I wouldn't call them uncommon. Ones I use somewhere between daily and semi-regularly:

* Pycharm * Datagrip * Charles * JDiskReport * TexturePacker * Android Studio and associated tools * Apache Directory Studio * Zed attack proxy

That's just stuff that I've used recently and on an ongoing basis... I feel like I see quite a bit more of it.

I used to use a thing called JMeter. But its GUI felt inferior in my view compared to typical Windows applications.

> The reason Java never got to the desktop (including browser) I believe was the startup time.

I think it's mainly the fact that it has always been very difficult to create executable files.

Running java requires you to install the given version of JRE instead of just downloading an application and starting it.

It was always very easy, just package the JRE with the application, use an installer like any other desktop application, or buy one of those commercial AOT compilers available since the start of century.

But that takes a lot of space

You could not fit it on a floppy

The 8 and 16 bit home computer scene are way past us.

There's also an expectation that memory footprint will be lower and that can contribute to speed by reducing GC time. The "JIT can do it too" arguments generally don't consider bounded memory.

Hehehe the old AOT vs JIT debate.

JITs can do great optimizations in theory. But in practice they have only so much time to do optimizations.

And startup time, binary distribution size, memory footprint matter too.