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
One of the neatest things I've been able to do is compile a .dll library "plugin" for an application which loads plug-ins by invoking a special exported symbol name like "int plugin_main()" using GraalVM and @CEntryPoint
The entrypoint function starts a Graal isolate via annotation params and no native code was needed
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.
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!
Hi, what's the deployment process like? Is there a program similar to warbler (for jruby) that builds a jar for a python program?
EDIT: I tried the native binary command here on a simple hello world script.
It downloaded some stuff in the background, built the entire python and java and embedded it into a 350 MB ELF binary on linux after 15 minutes of using 24 GB RAM and 100% CPU.
But I'd much prefer a smaller jar file which I can distribute cross-platform.
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.
> ... 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.
