Hacker News Reader

Comment by ShroudedNight | Hacker News Reader

I've been out of the loop on the AoT side of Java for a while now. How do these systems handle dynamic class-loading / code generation and things like hot patching?

View on HN

They don't. They explicitly refuse to compile an app that takes advantage of things that can't statically be determined to be available at compile time. There are a few exceptions, but it is best not to rely on them.

Given the reliance of most, if not all, major Java apps on reflection, factory patterns, type parameters/generics, and other dynamisms a la Spring (which had been practiced and preached for the longest time), I'd expect most apps won't benefit from AOT compilation then.

At least you'd still have AspectJ, because it can instrument bytecode before the AOT compiler sees it. Replacing Spring with Dagger would let you codegen your DI, but in 2020 you need a really good reason to blow that much eng work to improve your startup time.

One of the things that those sticking to Java 8 are missing out are the JIT caches that are now part of all major implementations, as those features were integrated into the FOSS variants from the commercial products.

> type parameters/generics

Those are purely compile-time constructs.

Yeah, it is not going to compile everything. For most Java apps, which were built in a world where startup time was a known disadvantage of the JVM, they will probably be better off with a JITed VM anyway. This is more of a new capability, allowing JVM languages the ability to move into usecases where they have never shined before. Like CLI apps, for example. I would expect most usage of AOT compilation will be for new software, not existing software.

That being said, generics and factory patterns aren't a problem for graal at all. Reflection and dynamic class loading are the biggest offenders.

How about GUI? Does JavaFX rely on dynamic classloading? (I presume so, given its XML-driven approach.) If so, would it be possible to refactor it away? Or perhaps introduce a preprocessing phase of some sort?

Gluon put out substrate which is supposed to do this:

https://github.com/gluonhq/substrate

Great that this is in the works.

Do you know about its workings?

I do not, other than it's based on GraalVM native image. I just know of its existence. I believe this is how gluon is pushing crossplatform for iOS since apple doesn't like the JVM JIT.

Reflection, factory patterns, type parameters/generics are are all handled by Graal. You just need to make the appropriate config file for your app.

Which is why most commercial AOT compilers for Java have been mostly focused on embedded deployments first, and as code caches or fast startup path on enterprise scenarios.

I think GraalVM can fall back to a JVM if it can’t AOT the whole thing?

Yeah, but most of the time it is used with --no-fallback. I personally don't really see the point of a fallback...I'd rather have it fail on me and know the reason why than to just become a normal JVM app as a fallback.

I assumed that, with fallback, it still did some JVM->machine code translation, maybe I'm misunderstanding how it all works. Also, it still produces a native executable, which is more convenient to distribute than a jar.

Buy isn't most of the dynamic load limited to the locally-available jars ?

Which means that the AOT generator has a finite set of classes to.comsider ?

And similarly, all the Spring/Boot dynamic features are a finite combination ?

(I have work on huge JVM systems with huge classpath directories but ultimately these run time polymorphism are finite?)

OpenJDK supports various kinds of AOT too, which also supports dynamic class loading. However the performance boost at startup is not as significant as with native-image/SubstrateVM/GraalVM because it stays spec compliant.

I haven't done much of this at all, but I believe dynamic class loading in graal's native-image AOT works when the string parameter in Class.forName(param) is a static string or a constant. This actually capturez a huge amount of apps, because their only dynamic class loading is for JDBC, and most apps know beforehand which driver they want to use.

Depends on the implementation. Like others said GraalVM doens't support it, GCJ has (had?) a JVM interpreter in the runtime to handle non-static stuff, or you could compile dynamically loaded classes separately to native code and later load them on the fly.

Reply on news.ycombinator.com