-
Notifications
You must be signed in to change notification settings - Fork 38.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for AOT processing with GraalVM tracing agent is not consistent #30511
Comments
Isn't there a more general problem? When using the agent with Say i don't use AOT processing, then try to use Shouldn't the |
If I run
That's because |
That's a very good question, @mhalbritter, and it might be the best solution for the time being. I've been advocating since early 2020 that applications and build tools need a first-class mechanism for determining when an application is running in the JVM with the GraalVM tracing agent active, but it hasn't gained much traction from the GraalVM team. In my last comment in that issue, I stated the following.
Lately, I believe that would be the better choice for the community. The @sdeleuze, @bclozel, @wilkinsona, @philwebb, @jhoeller, thoughts? |
Given the lack of traction on oracle/graal#2395, I think it makes sense to broaden our reliance on the NBT plugins setting |
The agent should detect the codepath used on native to generate the most accurate hints, so I don't think we should change Maybe we should raise that point in the next meeting we have with the GraalVM team? |
But we could change |
Yes, exactly -- like what That's actually what I meant to say previously, but I accidentally replied to the suggestion for changing the And that would make the |
I think that's what we should do, so I am moving this back to framework. |
I'm not sure I agree to that line of reasoning. IMHO the When running my integration tests while not using AOT mode with the agent attached, I would assume that it will generate hints for all dynamic behavior (reflection dependency injection etc.) and that both If I want to generate hints with the agent for the AOT code path, then I would need to run the tests in AOT mode, too. What's the idea behind |
This behavior looks correct to me as for some use cases, it is important to exercise the native code path on the JVM. The goal is not just to have more optimal hints, the goal is also to not break when running the app on native with tracing agent generated hints due to missing hints. |
Yes, but to be consistent with that statement, said code should run with AOT optimizations and it obviously can't. It looks wrong to me to require the native specific code path to run, while the most important bit, the one that avoids a bunch of code paths thanks to AOT, doesn't run. |
This commit refines how native agent detection works for both test and application executions. It rolls back the introduction of TestAotDetector done in 1113096 and instead updates AotDetector.useGeneratedArtifacts() to only detect "buildtime" and "runtime" imagecode system property values by leveraging a new method NativeDetector.inNativeImage(NativeDetector.Context...). Closes spring-projectsgh-30511
Overview
In Spring Framework 6.0.9, we made changes to the Spring TestContext Framework (TCF) to allow AOT processing with the GraalVM tracing agent and Native Build Tools.
Specifically, we introduced a
TestAotDetector
utility that is specific to the TCF. This detector considers the current runtime to be in "AOT runtime mode" if thespring.aot.enabled
Spring property is set totrue
or the GraalVMorg.graalvm.nativeimage.imagecode
JVM system property is set to any non-empty value other thanagent
.Since Spring Boot's testing support uses
AotDetector.useGeneratedArtifacts()
in various places, the Boot team should investigate whether Spring Boot Test should migrate fromAotDetector
toTestAotDetector
.Related Issues
The text was updated successfully, but these errors were encountered: