search

oracle / graal

GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
https://www.graalvm.org
Other
20.36k stars 1.63k forks source link

Offer API to interact with Assisted Configuration agent #3969

Open raphw opened 2 years ago

raphw commented 2 years ago

I am working with integrating Byte Buddy (a runtime code generation library) better with Graal to hopefully contribute with a seamless integration of many libraries that rely on Byte Buddy when it comes to the generation of subclass proxies. My experiments looks very promising and I would hope to make it more convenient if you can help me. I already filed another ticket, which I consider a bug but I would also need to directly interact with the assisted configuration agent, where I think a change is trivial but I wanted to know what you think about my proposal first.

Whenever Byte Buddy generates a class, I need to store that class file at a location that is available when building the native-image. For this purpose, I need to access the output directory that is set as -agentlib:native-image-agent=config-output-dir=. and also detect that the agent is running. I would then simply dump class files at the same location and expect users to include these classes later. Ideally, the Graal agent would assume a root directoy and add META-INF/native-image as a subfolder from there, but I can add some smart detection if that subfolder is set manually.

Other than that, I need to enable a more complex naming strategy where random class names follow some sort of pattern that are recognizable during execution. But if I can store a file during the agent's execution to summarize the mapping decision, I think that I can find a solution; given that I can detect the target location of the agent.

My suggestion is: add some functionality to the agent that it announces itself via a system property. For example, set a property org.graalvm.nativeimage.assisted.output that indicates that the agent is active and that exposes the target location.

sbrannen commented 2 years ago

add some functionality to the agent that it announces itself via a system property.

This part is closely related to:

raphw commented 2 years ago

It is! I might just follow the same convention, but I would also really appreciate if the Graal team added this or another mechanism to the agent. The problem is that, if several libraries follow this convention, the defacto adoption would have an impact on any future decision, so it might rather be decided sooner than later.

@sbrannen Are you writing files that you'd expect to be available during the native image's buildtime? How do you work around not knowing the set location?

sbrannen commented 2 years ago

I would also really appreciate if the Graal team added this or another mechanism to the agent. The problem is that, if several libraries follow this convention, the defacto adoption would have an impact on any future decision, so it might rather be decided sooner than later.

I agree.

@sbrannen Are you writing files that you'd expect to be available during the native image's buildtime? How do you work around not knowing the set location?

No, I'm not personally doing that.

The Spring Framework has a NativeDetector utility that we use to influence the code path taken when running within a native image. So when using the agent, we have to manually set that system property (to a non-null value -- we just pick "agent" because it makes sense and can be used to differentiate between the agent, build-time, and run-time).

2395 expounds a bit on that.

rodrigar-mx commented 2 years ago

Thank you for sharing your proposal. A member of the Dev team will take a look into it shortly.

raphw commented 2 years ago

I adopted the same convention as the Spring framework and it works as expected. I hope this can become official at some point!

vjovanov commented 2 years ago

Have you tried using experimental-class-define-support with the agent? This should output all the classes into a folder structure known to Native Image.

The classes would still need a stable name, but other than that all should work.

raphw commented 2 years ago

Yes, it would be useful for other things, too, though.

The mentioned feature fails on me, though: https://github.com/oracle/graal/issues/3968

peter-hofer commented 2 years ago

@raphw @vjovanov the stable name is arguably up to the class generator. If it reproducibly generates the same class data, then stable names can be assigned by hashing like experimental-class-define-support does.

The mentioned feature fails on me, though: #3968

You probably mean #3974, I'll have a look.

raphw commented 2 years ago

Yes, I meant the latter issue. I just tested with the latest Graal release and the null pointer still occurs.