Support agents at image generation time

[thegreystone]

It would be great if agents could be supported at image generation time, so that the instrumented code would be used in the final image.

[cstancu]

How do you envision such a feature? It seems to me that bytecode instrumentation via agents is an orthogonal feature. You can run an agent on your code, instrument it, and then feed it to native-image.

[tylerbenson]

I'm not super familiar with Graal's build options, but what I would be hoping for is a way to reuse the existing javaagent tooling at build time instead of run time.

[peter-hofer]

I think supporting existing Java agents (or even JVMTI agents) in the image build would not be straightforward because they are quite often more dynamic than just instrumenting bytecode when it is first loaded, and agents can also affect the code of the image build itself and not just application and library classes. I'm also not sure whether they work currently work well with JVMCI. This could be feasible to implement in a limited scope without support for redefinition or retransformation.

[peter-hofer]

(closed unintentionally)

[bsideup]

It would be nice if native-image will support one-time class file transformations.

Preferably with the existing Java Agents API (simulating premain), but if a separate API will be required, that's not a blocker for our use cases.

[thegreystone]

Sorry for not following up. Agreed, limited functionality will go a long way - feeding the classes to be part of the image through the agent(s) and allowing them a go at transforming them will go a long way for my use case(s) too.

[dougxc]

I'm also not sure whether they work currently work well with JVMCI

JVMCI and Graal work fine with JVMTI agents (it's a bug if they don't). We also load method substitution bytecode from disk to avoid instrumentation effects.

[raphw]

This would be very relevant for me, too. I have a monitoring application for which I would like to support this. If Graal could mimic the instrumentation API, this would of course be a plus but a different API that only supports registering a ClassFileTransformer for all classes that are added to the image would solve most use cases, I think.

If I may suggest an implementation: I do not think that such an agent should affect the classes of the JVM process that is building the image as this might interfere with the build process. Instead, there should be an API that allows for:

a) Registering a ClassFileTransformer for transforming all classes before being added to the image. The arguments for Module, ClassLoader, Class and ProtectionDomain could simply be null, you basically only need to present the class name and its byte code.
b) Offer an API to define additional classes and to find classes that are included in the image such as:

interface GraalInstrumentation {
  void addClassFileTransformer(ClassFileTransformer cft);
  byte[] findClass(String className);
  void addClass(byte[] classFile);
  void include(JarFile file);
  void addConfig(ReflectionConfig config);
  void addEntryPoint(String className);
}

The last method would be used to register classes with some method to execute before the instrumented program that was already added, similar to premain but without the possibility to request an instrumentation instance.

Given this, one could offer an API for the Graal native-image compiler where the Instrumentation interface was replaced with the above. The same should then ideally also work for standard AOT compilation.

As a bonus one could consider to supply a pseudo class loader to the above class file transformer. This class loader could then return class files on the getResourceAsStream method. This would make it a bit easier to reuse existing agent code.

For my purposes, this would be sufficient.

[thomaswue]

@thegreystone Would the approach as described by @raphw also work for your use case?