33 ms·

I hope at some point we'll get AOT-only mode (or compile to native) and maybe even cross-compilation.

invalidname 8d ago
We have that in Codename One, yes it's not really "Java" but it compiles bytecode AOT and cross compiles to some of the platforms.
nirvdrum 8d ago
If you haven't checked it out yet, GraalVM's Native Image [1] already let's do AOT compilation suitable for distribution. You have to do some configuration to deal with reflection and dynamic class loading since there's no JVM in the produced build, but it comes with tooling to simplify that. And that restriction is being addressed by Project Crema [2]. [1] -- https://www.graalvm.org/latest/reference-manual/native-image/ https://www.graalvm.org/latest/reference-manual/native-image... [2] -- https://github.com/oracle/graal/issues/11327 https://github.com/oracle/graal/issues/11327
- Twirrim 8d ago
  The slight drawback is that AOT compiled Java code's performance isn't as good as the JIT compiled form running on the JVM. There's a reason why folks keep coming back to JIT compilation. It's hard to beat the value that can be gained from actually gathering data on how the code is actually used, which leads to a whole set of potential optimisations (which is the problem Profile Guided Optimisation attempts to solve for AOT compiled code.) The JVM is arguably one of the most advanced and capable JITing runtimes. As with anything it's a trade off. Fast start times, pretty fast running (I think maybe less memory usage?); vs the full JIT speed you can get on the JVM at the cost of start-up speed and memory consumption. All depends on what you want to use the application for. If you're talking something like a serverless function, go native. If you're talking production server where you're measuring runtime in more than dozens of minutes, probably better to stick to the JVM & JIT.
  - bebop 8d ago
    Full agreement with everything you said. Just one detail to add on serverless (and potentially in a scheduled environment like k8s), startup time can be an order of magnitude or more faster in a native build. For instance, I have some quarkus applications that can take 10 seconds to ready running via the jre that take 10ms or less to start as a graalvm built binary.
    - silon42 7d ago
      I wish JVM could at least recover the memory after some time and drop at runtime what quarkus / AOT drops at build time.
      - samus 7d ago
        It can and already does. It mostly depends on the GC. Or do you mean non-heap memory that the runtime uses?
  - pjmlp 7d ago
    Depends on how much effort, like on C and C++, you are willing to put into PGO metadata for the compiler and linker.
    - samus 6d ago
      Even if you can gather that PGO metadata a running application won't be able to adapt to changes in that data.
      - pjmlp 6d ago
        It works well enough for systems software written in C and C++, where Java still remains a niche option, even when it could deliver.
        samus 5d ago
        Java has many dynamic features where runtime optimization is required to remove the overhead. Virtual method calls are opt-out instead of opt-in, and there is an open world assumption. The possibility of doing stack allocation of objects depends on the call hierarchy (in the future it will get a bit easier with value objects). Also, C/C++ are not managed languages, therefore the effects of bad optimization don't hurt as much.
exabrial 8d ago
progress, not perfection! Java is on fire right now with new stuff landing. We'll get there!
layer8 8d ago
That would place significant limitations on the applications that can be compiled. As the JEP explains: “Features such as dynamic class loading, dynamic linkage, dynamic dispatch, and dynamic reflection bring vast expressive power, and have been fundamental to the platform's success. HotSpot handles these features naturally, while static compilers struggle with them. Even heroic amounts of static analysis cannot make up for the fact that these features require many decisions to be made at run time. Implementors of static compilers for Java code have therefore resorted to incompatible constraints, such as closed-world assumptions, and to putting significant burdens on developers, such as having to identify in advance the classes eligible for reflection.” Therefore I don’t see AOT-only becoming an integral part of standard Java in the foreseeable future.
- java-man 8d ago
  we are not talking about fully supporting dynamic loading, because it's not needed in all the cases, and in some cases, the list of allowed classes in the application can (or must) be limited. i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++.
  - samus 7d ago
    > i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++. What is the objective here? Startup latency or throughput? Both will be vastly improved by JEP 544.
- jasomill 8d ago
  It works pretty well for greenfield projects on .NET, so long as you can live without third-party libraries that don't support AOT. Existing code bases can be a pain, though, especially applications that heavily rely on things like C++/CLI and COM Interop that basically need to be rewritten from scratch. Which is not to say that it's intended to replace the traditional JIT runtime in applications where it isn't troublesome, because it's not.
samus 7d ago
That won't be necessary when 544 lands. The only thing you'd gain is not having to ship the JIT compilers in a jlink build. Also, I'm fairly certain that the JIT compilers can be turned off with some combination of runtime flags to ensure only the AOT generated code is executed.
za3faran 7d ago
GraalVM native-image already provides an AOT-only executable.

We have that in Codename One, yes it's not really "Java" but it compiles bytecode AOT and cross compiles to some of the platforms.

nirvdrum 8d ago

If you haven't checked it out yet, GraalVM's Native Image [1] already let's do AOT compilation suitable for distribution. You have to do some configuration to deal with reflection and dynamic class loading since there's no JVM in the produced build, but it comes with tooling to simplify that. And that restriction is being addressed by Project Crema [2]. [1] -- https://www.graalvm.org/latest/reference-manual/native-image/ https://www.graalvm.org/latest/reference-manual/native-image... [2] -- https://github.com/oracle/graal/issues/11327 https://github.com/oracle/graal/issues/11327

Twirrim 8d ago
The slight drawback is that AOT compiled Java code's performance isn't as good as the JIT compiled form running on the JVM. There's a reason why folks keep coming back to JIT compilation. It's hard to beat the value that can be gained from actually gathering data on how the code is actually used, which leads to a whole set of potential optimisations (which is the problem Profile Guided Optimisation attempts to solve for AOT compiled code.) The JVM is arguably one of the most advanced and capable JITing runtimes. As with anything it's a trade off. Fast start times, pretty fast running (I think maybe less memory usage?); vs the full JIT speed you can get on the JVM at the cost of start-up speed and memory consumption. All depends on what you want to use the application for. If you're talking something like a serverless function, go native. If you're talking production server where you're measuring runtime in more than dozens of minutes, probably better to stick to the JVM & JIT.
- bebop 8d ago
  Full agreement with everything you said. Just one detail to add on serverless (and potentially in a scheduled environment like k8s), startup time can be an order of magnitude or more faster in a native build. For instance, I have some quarkus applications that can take 10 seconds to ready running via the jre that take 10ms or less to start as a graalvm built binary.
  - silon42 7d ago
    I wish JVM could at least recover the memory after some time and drop at runtime what quarkus / AOT drops at build time.
    - samus 7d ago
      It can and already does. It mostly depends on the GC. Or do you mean non-heap memory that the runtime uses?
- pjmlp 7d ago
  Depends on how much effort, like on C and C++, you are willing to put into PGO metadata for the compiler and linker.
  - samus 6d ago
    Even if you can gather that PGO metadata a running application won't be able to adapt to changes in that data.
    - pjmlp 6d ago
      It works well enough for systems software written in C and C++, where Java still remains a niche option, even when it could deliver.
      - samus 5d ago
        Java has many dynamic features where runtime optimization is required to remove the overhead. Virtual method calls are opt-out instead of opt-in, and there is an open world assumption. The possibility of doing stack allocation of objects depends on the call hierarchy (in the future it will get a bit easier with value objects). Also, C/C++ are not managed languages, therefore the effects of bad optimization don't hurt as much.

exabrial 8d ago

progress, not perfection! Java is on fire right now with new stuff landing. We'll get there!

layer8 8d ago

That would place significant limitations on the applications that can be compiled. As the JEP explains: “Features such as dynamic class loading, dynamic linkage, dynamic dispatch, and dynamic reflection bring vast expressive power, and have been fundamental to the platform's success. HotSpot handles these features naturally, while static compilers struggle with them. Even heroic amounts of static analysis cannot make up for the fact that these features require many decisions to be made at run time. Implementors of static compilers for Java code have therefore resorted to incompatible constraints, such as closed-world assumptions, and to putting significant burdens on developers, such as having to identify in advance the classes eligible for reflection.” Therefore I don’t see AOT-only becoming an integral part of standard Java in the foreseeable future.

java-man 8d ago
we are not talking about fully supporting dynamic loading, because it's not needed in all the cases, and in some cases, the list of allowed classes in the application can (or must) be limited. i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++.
- samus 7d ago
  > i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++. What is the objective here? Startup latency or throughput? Both will be vastly improved by JEP 544.
jasomill 8d ago
It works pretty well for greenfield projects on .NET, so long as you can live without third-party libraries that don't support AOT. Existing code bases can be a pain, though, especially applications that heavily rely on things like C++/CLI and COM Interop that basically need to be rewritten from scratch. Which is not to say that it's intended to replace the traditional JIT runtime in applications where it isn't troublesome, because it's not.

samus 7d ago

That won't be necessary when 544 lands. The only thing you'd gain is not having to ship the JIT compilers in a jlink build. Also, I'm fairly certain that the JIT compilers can be turned off with some combination of runtime flags to ensure only the AOT generated code is executed.

za3faran 7d ago

GraalVM native-image already provides an AOT-only executable.