BTW: We (the GraalVM team) maintain a full-blown LLVM bitcode runtime that can be embedded in Spring or any other JVM application and compiled to native: https://github.com/oracle/graal/tree/master/sulong
As Thomas mentioned, we continue our mission to run programs faster and more efficiently. So yes, the GraalVM Docker images are still maintained and now include images with the new GraalVM 25 release.
I hope it isn't used in production yet because we still consider the use of native extensions experimental in GraalPy. However, we definitely see a need for this and will push it forward. If anyone wants to give this a try, please feel free to reach out to us.
Although GraalPy can create standalone applications [1], you don't have to turn your hello world script into a self-contained binary. You can, of course, create a JAR that depends on GraalPy, or a fat JAR that contains it, and deploy it just like any other Java application.
We are still updating our docs to mention more details on this and publish some guides, apologies for the delay.
We also want to make it easy for Python package maintainers to test and build wheels for GraalPy. It's already available via setup-python, and we are adding GraalPy support to cibuildwheel. If you need any help, please reach out to us!
> ... the JVM can intercept the resulting SIGSEGV ("Signal: Segmentation Fault"), look at the return address for that signal, and figure out where that access was made in the generated code. Once it figures that bit out, it can then know where to dispatch the control to handle this case — in most cases, throwing NullPointerException or branching somewhere.
Also, reflection is supported in AOT mode. The analysis, however, does require reachability metadata in some cases. In the best case, libraries provide and maintain appropriate configuration for this. Reachability metadata can also be shared via https://github.com/oracle/graalvm-reachability-metadata.
JIT compilation requires additional CPU and memory resources at run-time, which AOT compilation can avoid. This also means that for a native executable, the compilation work only needs to be done once at build-time and not per process.
The students "measured noticeable reductions in terms of memory footprint of up to 43%" [1] in some preliminary experiments. More from the accompanying blog post:
"We also hope that the Minecraft community builds on our work and helps benchmark different configurations for native Minecraft servers in more detail and in larger settings."
Please feel free to share any numbers on CPU/memory usage with us!
I don't think the student looked into that at all, but I guess it depends on what the Java client uses for drawing. GraalVM Native Image currently doesn't support AWT on Linux/JDK17+, but we are working on fixing that soon.