I have been tracking the progress of GraalVM because I am constantly paranoid about the resource load that is caused by my team’s on-rio processes.
I can confirm that the GraalVM profiler works with the GradleRIO/JVM setup when remote profiling from an external linux machine, but that is all the Graal-related testing I have done.
Things I am curious about:
- AOT Java compilation should reduce overhead of JVM, as most of the work is already done, and there is just a stripped VM running inside of the compiled native binary
- GraalVM allows Java and native libraries to mesh with eachother natively instead of through something like JNI. I am interested in this for two reasons (correct me if im wrong):
- This should let us use some dependencies that are vital to the 5024 codebase like Eigen and Drake without needing to write a JNI wrapper
- This should allow me to create Java -> C++ bindings of our team library without needing to embed a JVM in the C++ application (I have a few personal projects written in c-family languages, and using a completely separate buildsystem from the core library)
- GraalVM should allow us to write high-level autonomous scripts through its Python3 interface. This may actually allow us to write a very high level library, and let our strategy team write the autonomous scripts instead of that being a pure software-dev task during build season.
I have seen some talk in the GraalVM and OpenJDK GitHub repos about getting the new VM to run on arm systems, and it seems that the OpenJDK-11 package for armv7l already has the core GraalVM compiler built in?
Anyways, I’m mostly just sharing something I have been thinking about in case anyone else wants something to play around with or knows something I don’t about the progress of GraalVM on arm 32 systems.