OpenTelemetry agent adaption for GraalVM native image

[ziyilin]

Introduction

GraalVM native image can improve Java applications's startup performance and runtime memory footprint significantly. But as everything is compiled in advance and no bytecode is left at runtime, agent instrumentation at runtime is not possible for native image.
The agent support PR from GraalVM community proposes an approach to address such scenario. It detects the transformed classes and compiles them into the native image. But still a few things need to do at the agent side:

• premain initializations: Original premain initializations in agent can't be simply applied to the native image, because it may do something unnecessary and incompatible with native image. For example, OTel installs bytebuddy during premain phase, but it is unnecessary in native image.
• JDK class transformations: GraalVM cann't take the instrumented JDK classes at build time for two major reasons: 1). GraalVM is a Java application as well. Modified JDK classes may lead to unexpected behaviors at build time. 2). GraalVM modified JDK classes too, conflicts are unacceptable. Therefore, agent side should rewrite the JDK class transformations with GraalVM's API.

This PR worked on the above two sides. Together with the agent support PR, the spring boot demo application can work with OTel agent now (see the next section for details).

But this PR only made a minimal adaption to get a few demo applications work. We hope this PR is the start point for OTel agent native adaption. More people in the community can join to complete the adaption.

Run the Spring Boot Demo Application

Demo project:
spring-boot.zip

Prequisite

• Build the agent support PR to get the GraalVM JDK.
• Or download the [dev version binary for the experiment only.
• Make sure your GRAALVM_HOME system variable refers to one of the above GraalVM binaries.

Steps

1. Build this PR
   1.1 Install graal-sdk-instru.jar. The graal sdk jar can be compiled from the agent support PR. A precompiled graal-sdk-23.0.2-instru.jar is enclosed in the demo project zip file. Run mvn install:install-file -Dfile=path/to/graal-sdk-23.0.2-instru.jar -Dpackaging=jar -DgroupId=org.graalvm.sdk -DartifactId=graal-sdk -Dversion=23.0.2-instru to install it for later usage.
   1.2 ./gradlew publishToMavenLocal. Build and install jars to local maven repository.
   1.3 mvn install:install-file -Dfile=./instrumentation-native-support/build/libs/instrumentation-native-support-2.3.0-alpha-SNAPSHOT.jar -Dpackaging=jar -DgroupId=io.opentelemetry.javaagent -DartifactId=instrumentation-native-support -Dversion=2.3.0-alpha-SNAPSHOT. Add the native support jar to your local maven repository for later usage. Note: the version can be changed. Please modify it according to your actual value.

2. Cd to the root of unzipped demo project

3. mvn package: Build the jar package of this project

4. ./run.sh --jvm --collect --log: Execute the project in JVM mode, enabling OpenTelemetry agent to log monitoring data. Meanwhile, native-image-agent is enabled to collect transformation classes and other dynamic data. When this step ends, data is dumped to native-configs directory.

5. ./build.sh: Build the native image.

6. ./run.sh --svm --log: Run the native image application.

7. curl localhost:2327: Send a request to the application.

Limitations

GraalVM native image only has one classloader at runtime, so it cannot support classloader based class isolation which is used in the OTel agent. For example, the inst/**/*.classdata files are renamed back to class and loaded in the classpath at GraalVM build time for now. One solution is to shade them to new packages, but we are not sure about its impact. It is welcomed for discussion.

[linux-foundation-easycla]

• ✅login: ziyilin / (7ef6288)

The committers listed above are authorized under a signed CLA.