GraalVM 24.0+ breaks the native-image driver (in native mode) #556
Comments
|
Note that the macro builds with |
|
Draft fix for this. Needs more testing. jerboaa/graal@no-jlinking-fixes-7085...jerboaa:graal:mandrel-cgroups-bb-dm |
|
It looks like the cgroup change is a 24.0 only feature for now. It doesn't seem to affect 23.1 (current release branch as of today at fd442af), so I'm adjusting the milestone. |
Test run with this patch including quarkus native tests: |
It's in the 23.1 release tree now as well: oracle@efbbbe7 |
First, we use a separate accessor for page-alignedness as it doesn't need the more sophisticated initialization of the directMemory field. Next, ensure PhysicalMemory initialization is serialized and when it is, set directMemory to a static value so that the container code can finish initialization without introducing a cyle. The final directMemory value based on the heap size is then published to JDK code by setting the VM init level to 1. Therefore, application code would use the non-static value as the upper bound. Closes: #556
|
Fixed for 23.1 in #569, still an issue with 24.0-dev |
|
oracle#7478 is the upstream PR for this. |
First, we use a separate accessor for page-alignedness as it doesn't need the more sophisticated initialization of the directMemory field. Next, ensure PhysicalMemory initialization is serialized and when it is, set directMemory to a static value so that the container code can finish initialization without introducing a cyle. The final directMemory value based on the heap size is then published to JDK code by setting the VM init level to 1. Therefore, application code would use the non-static value as the upper bound. Closes: #556
|
oracle#7553 is the fix for master (24.0+) which got merged recently. Closing. |
First, we use a separate accessor for page-alignedness as it doesn't need the more sophisticated initialization of the directMemory field. Next, ensure PhysicalMemory initialization is serialized and when it is, set directMemory to a static value so that the container code can finish initialization without introducing a cyle. The final directMemory value based on the heap size is then published to JDK code by setting the VM init level to 1. Therefore, application code would use the non-static value as the upper bound. Closes: #556 (cherry picked from commit 1ae2dc0)
Description
After the move of GraalVM master (24.0) to use the JDK's metrics classes for container support, there is a cyclic dependency issue that needs to be solved for Mandrel.
PhysicalMemoryclass newly depends on the JDK's metrics classes, which use NIO in unpatched OpenJDK.Target_jdk_internal_misc_VM.javainternally usesRuntime.getRuntime().maxMemory()for the initial direct memory size (overriden with-R:MaxDirectMemorySize), which is the heap size.Runtime.getRuntime().maxMemory()inHeapImpl.javausesPhysicalMemory.size().Therefore, there is an initialization cycle resulting in a stack overflow. At runtime, it looks like this:
We need to find a way to set the initial direct memory size (without using NIO) and/or without creating this cycle. This isn't a problem in GraalVM Community since it uses labsjdk as a base, which has a patch avoiding this issue. Thus, it's a Mandrel only issue.
The issue can be reproduced when trying to generate the native-image generator as a native image itself on a recent mandrel build and then trying to run
--versionon the result:The text was updated successfully, but these errors were encountered: