[GR-55707] Java Agents Support in Native Image

[alina-yur]

This ticket summarizes the current status and next steps for Java agent support in Native Image.

Current status

At build time, bytecode transformation can be done by passing a Java agent to Native Image with -J-javaagent:agent.jar. Things to note:

• The agent is running and transforming all classes at build time.
• The premain of the agent is only executed at build time.
• The agent is currently marked as link-at-build-time so all of the classes need to be present in the agent jar.
• The agent should not touch the classes that are used by native-image itself, as this might interfere with the build or result in unpredictable behavior at run time. Instrumenting JDK classes should work to a large degree but there are a few pitfalls:
  • Too complex instrumentation (e.g., introducing Java heap allocation or synchronization) may break the image build or execution at run-time (Native Image assumes for some JDK methods that they only contain trivial code).
  • Native Image substitutes some JDK code with a custom implementation. Instrumenting such JDK code is not possible as the substitution takes precedence (i.e., it will look as if the JDK code was not instrumented).

Goals

• Simplify and improve agent support at build time:
  • Support agents at image generation time
  • A potential implementation
• Explore removing the limitation of linking at build time
• Explore executing premain at runtime
• Explore limiting the scope of Native Image classes that the agent can transform

Non-goals

• Allowing agents to transform classes at runtime

[cemo]

@alina-yur, Is there any coordinated effort from Oracle to resolve this issue? I see there is an open PR but I think it is not addressed by current maintainers of the project. At the end of that effort that PR might be not accepted as well. Is it not a good idea to review that PR and making a better way?

It sounds probably strange but after that PR resolved adoption of the Graal will increase dramatically. Many companies are using agents for APM tools and every single release we are reading release notes to see that this issue resolved or not.

[adinn]

It sounds probably strange but after that PR resolved adoption of the Graal will increase dramatically. Many companies are using agents for APM tools and every single release we are reading release notes to see that this issue resolved or not.

I think you need to reset your expectations of any 'solution'. The qualifications Olga mentioned are not just something to be 'resolved' by a clever redesign. They are intrinsic to what can be achieved here -- because they rule out things that many agents rely on being able to do (there are more issues -- for example, agents that depend on creating service threads under their premain method). In consequence there will be a lot of cases where agents that are used at runtime on the JVM cannot be used at build time to modify behaviour of a generated native image.

As an example, my agent, Byteman, as currently designed, cannot possibly be used to instrument a native image at build time. I am not going to say it is impossible to implement an equivalent for GraalVM Native but I currently don't know how to do it (and, yes, I designed and implemented all the core functionality of Byteman). My expectation is that my (many thousands of) users who rely on using Byteman for testing, tracing and debugging are never going to be able to use it for those purposes with a GraalVM Native app.

Luckily, my users can still benefit from using Byteman on the JVM during development and maintenance of a GraalVM Native app and the tight equivalence in behaviour of a GraalVM Native vs JVM deployment means they can still test, trace and debug most problems that way. However, I do have a significant number of users who rely on Byteman to troubleshoot problems in live deployments and they are out of luck if they choose to deploy using GraalVM Native.

That said, I fully accept that there are agents where build time vs runtime instrumentation makes no difference. So that means a resolution of this issue would be very welcome. Just remember that any such solution will not be universal.

[chenzhiguo]

I am very concerned about when this feature will be implemented?