Skip to content
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

[GraalVM] Question: A few GraalVM supporting questions #8174

Open
ziyilin opened this issue Jan 9, 2025 · 0 comments
Open

[GraalVM] Question: A few GraalVM supporting questions #8174

ziyilin opened this issue Jan 9, 2025 · 0 comments
Labels

Comments

@ziyilin
Copy link

ziyilin commented Jan 9, 2025

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.

  1. 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?

  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants