5 ms·

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 patch

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?

darksaints 6y ago
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.
- tannhaeuser 6y ago
  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.
  - erik_seaberg 6y ago
    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.
    - pjmlp 6y ago
      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.
  - ebruchez 6y ago
    > type parameters/generics Those are purely compile-time constructs.
  - darksaints 6y ago
    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.
    - MaxBarraclough 6y ago
      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?
      - vips7L 6y ago
        Gluon put out substrate which is supposed to do this: https://github.com/gluonhq/substrate https://github.com/gluonhq/substrate
        MaxBarraclough 6y ago
        Great that this is in the works. Do you know about its workings?
        vips7L 6y ago
        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.
  - lenkite 6y ago
    Reflection, factory patterns, type parameters/generics are are all handled by Graal. You just need to make the appropriate config file for your app.
  - pjmlp 6y ago
    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.
- fiddlerwoaroof 6y ago
  I think GraalVM can fall back to a JVM if it can’t AOT the whole thing?
  - darksaints 6y ago
    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.
    - fiddlerwoaroof 6y ago
      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.
- embrassingstuff 6y ago
  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?)
  - thu2111 6y ago
    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.
  - darksaints 6y ago
    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.
fulafel 6y ago
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.

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?

darksaints 6y ago

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.

tannhaeuser 6y ago
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.
- erik_seaberg 6y ago
  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.
  - pjmlp 6y ago
    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.
- ebruchez 6y ago
  > type parameters/generics Those are purely compile-time constructs.
- darksaints 6y ago
  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.
  - MaxBarraclough 6y ago
    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?
    - vips7L 6y ago
      Gluon put out substrate which is supposed to do this: https://github.com/gluonhq/substrate https://github.com/gluonhq/substrate
      - MaxBarraclough 6y ago
        Great that this is in the works. Do you know about its workings?
        vips7L 6y ago
        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.
- lenkite 6y ago
  Reflection, factory patterns, type parameters/generics are are all handled by Graal. You just need to make the appropriate config file for your app.
- pjmlp 6y ago
  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.
fiddlerwoaroof 6y ago
I think GraalVM can fall back to a JVM if it can’t AOT the whole thing?
- darksaints 6y ago
  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.
  - fiddlerwoaroof 6y ago
    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.
embrassingstuff 6y ago
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?)
- thu2111 6y ago
  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.
- darksaints 6y ago
  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.

fulafel 6y ago

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.