You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi DD team, you did a great job to support building agent into GraalVM native image. DD's current agent support is very concise and user friendly. I'm working with GraalVM team to provide supports for Java agent in GraalVM, and deeply inspired by your work. For now, the premain support has been merged into GraalVM. Hopefully you don't need to instrument GraalVM framework in the future.
Meantime, I'm interested in how you tackled with a few technical bottlenecks.
JDK class transformation problem.
a. Build time interference: When agent is attached at native image build time, it may transform JDK classes that are used by GraalVM building process, resulting unpredicted building time behaviors. Our solution is to introduce a proxy agent that filters transformation of JDK and GraalVM classes out, and forward other transformations to the actual agent. How did DD solve this problem?
b. Runtime invalidation: GraalVM has modified some JDK classes with its substitution mechanism. If a JDK class is transformed by agent and substituted by GraalVM at the same time, the agent transformation could be invalidated by GraalVM substitution. How did DD solve this problem?
Agent dependencies problem. Agent's own dependency classes are shaded at agent packaging time, and loaded at runtime by agent's special classloaders. GraalVM loads all classes to compile by NativeImageClassLoader by reading class paths specified by native-image's -cp option. Our current solution is to manually package the agent's dependencies into a standalone jar and append it to the native-image's class path. I'm curious how DD managed to let GraalVM know how to load the agent's shaded dependencies.
Thank you very much.
The text was updated successfully, but these errors were encountered:
Hi DD team, you did a great job to support building agent into GraalVM native image. DD's current agent support is very concise and user friendly. I'm working with GraalVM team to provide supports for Java agent in GraalVM, and deeply inspired by your work. For now, the premain support has been merged into GraalVM. Hopefully you don't need to instrument GraalVM framework in the future.
Meantime, I'm interested in how you tackled with a few technical bottlenecks.
JDK class transformation problem.
a. Build time interference: When agent is attached at native image build time, it may transform JDK classes that are used by GraalVM building process, resulting unpredicted building time behaviors. Our solution is to introduce a proxy agent that filters transformation of JDK and GraalVM classes out, and forward other transformations to the actual agent. How did DD solve this problem?
b. Runtime invalidation: GraalVM has modified some JDK classes with its substitution mechanism. If a JDK class is transformed by agent and substituted by GraalVM at the same time, the agent transformation could be invalidated by GraalVM substitution. How did DD solve this problem?
Agent dependencies problem. Agent's own dependency classes are shaded at agent packaging time, and loaded at runtime by agent's special classloaders. GraalVM loads all classes to compile by
NativeImageClassLoader
by reading class paths specified bynative-image
's-cp
option. Our current solution is to manually package the agent's dependencies into a standalone jar and append it to the native-image's class path. I'm curious how DD managed to let GraalVM know how to load the agent's shaded dependencies.Thank you very much.
The text was updated successfully, but these errors were encountered: