graal

graal copied to clipboard

While working on GraalVM native image support for the Spring Framework, we have noticed that we could really benefit from having the GraalVM native image agent automatically set the value of the org.graalvm.nativeimage.imagecode JVM system property to agent (or something similar).

The reason we need this is that we have certain code paths that get executed while running with the agent that will never be executed within a native image. Without such a flag available while running with the agent, the agent will generate native image configuration (e.g., in reflect-config.json) that is inappropriate for the actual runtime behavior within a native image.

For example, in Spring's SerializableTypeWrapper we have a check that avoids proxy creation for Serializable. Although this check works as expected within a native image, when we execute this code path while running with the agent, the check will evaluate to false, and consequently Spring will create a dynamic proxy that implements java.io.Serializable which is not supported within a native image.

As a workaround, we are running the agent with -Dorg.graalvm.nativeimage.imagecode=agent:

https://github.com/sbrannen/spring-framework/blob/46bca56460a720ee0c89b9a75fedd4d877ba0f4e/gradle/graalvm-native-image-testing.gradle#L16

And we have modified our GraalVmDetector utility class as follows.

https://github.com/sbrannen/spring-framework/blob/46bca56460a720ee0c89b9a75fedd4d877ba0f4e/spring-core/src/main/java/org/springframework/core/GraalVmDetector.java#L33-L42

This allows Spring to choose the correct code path (while running with the agent) that will be the actual code path executed within a native image.

In summary, we would be very grateful if the GraalVM native image agent would automatically set the value of the org.graalvm.nativeimage.imagecode JVM system property to agent (or something similar), and we are confident that other framework and application developers will also benefit from a standardized solution to this.

I actually consider this an enhancement rather than a bug, but the template automatically selected the bug label.

Hey @sbrannen we have been debating whether or not to add this flag, and for the time being, given that there is feasible work around we have decided to backlog this item as is. The native-image team is looking to enhance its user experience while retaining an appropriate API surface. If you still feel strongly about necessity of this feature, feel free to add more scenarios that will benefit from this and we will happily reassess our decision.

This issue is still relevant.

• The official Maven and Gradle plugins from the GraalVM Native Build Tools project set the system property to agent whenever the agent is used (both for the application and for tests).
• JUnit Jupiter 5.9.1 introduced @EnabledInNativeImage and @DisabledInNativeImage annotations for testing with a GraalVM native image that check for a non-empty property value in order to support buildtime, runtime, agent, and any additional values that may be supported in the future.
• The Spring Framework still checks for a non-null value for the system property and relies on that when using the agent as well. Consequently, Spring Boot and all Spring portfolio projects rely on the same behavior.
• @raphw uses the same agent value "convention" for Byte Buddy support.
  • https://github.com/oracle/graal/issues/3969#issuecomment-963915625
• Since Native Build Tools are becoming the most common way to build and test native images, I imagine that countless other projects also now rely on the property being set when the agent is used -- without realizing that it's not an officially supported feature of the agent.

In light of the above, please reopen this issue and reconsider having the agent automatically set the system property to agent (or some other value). If you are not willing to do that, please have the agent set a different system property that can be queried in order to determine if code is running on the JVM with the agent enabled.

It might also be beneficial to introduce a new inImageAgentCode() method in ImageInfo.

Thanks for your consideration!