Implement auto instrumentation under GraalVM static compilation on OTel... Zihao Rao & Huxing Zhang

Summary

In this talk from Alibaba Cloud, speakers Hin and How explore the implementation of auto-instrumentation under the GraalVM static compilation for the OpenTelemetry (otel) Java agent. They discuss the challenges modern Java apps face, such as startup time and memory consumption, and how GraalVM's native image can mitigate these issues. The presentation covers the compilation process, the impact on the Java ecosystem, and introduces a solution to maintain observability with Java agents in a native image environment. The demonstration showcases the improved startup speed and data collection capabilities, with future work aimed at more comprehensive testing and combining phases for efficiency.

Takeaways

• 😀 The talk is about implementing auto-instrumentation under GraalVM static compilation for the OpenTelemetry (otel) Java agent.
• 🔍 The speakers are from Alibaba Cloud and aim to address the challenges of startup time and memory consumption in modern Java applications.
• 🚀 GraalVM was introduced to eliminate JVM initialization and JIT compilation, which significantly reduces the startup time and memory footprint of Java applications.
• 🛠 The native image compilation process involves point-to-analysis, class initialization, and snapshotting to create operating system-specific native images.
• 🔄 GraalVM brings challenges to the Java ecosystem, such as reduced support for dynamic features and platform independence, and impacts Java agents used for observability.
• 🔧 The solution involves a pre-running phase and a static compilation phase, with the otel Java agent and a new native image agent playing key roles.
• 🔬 The native image agent helps collect transformed classes and dynamic configurations, which are necessary for maintaining Java agent functionality in a native environment.
• 📈 The demonstration shows a significant improvement in startup speed and memory overhead when using the proposed solution compared to traditional JVM-based approaches.
• 📝 The future work includes more comprehensive testing and potentially combining the pre-running and static compilation phases for a more streamlined process.
• 🔒 The solution is not yet in production use but is a promising intermediate result that requires further testing and refinement.
• 🤝 There is interest in integrating this solution into the serverless product layer for faster startup and scaling of small applications.

Q & A

What is the main topic of the talk presented by Hin and How from Alibaba Cloud?

The main topic of the talk is about implementing auto-instrumentation under GraalVM static compilation on the OpenTelemetry (otel) Java agent.

What are the two key challenges modern Java applications face according to the talk?

The two key challenges modern Java applications face are startup time and memory consumption.

What does the GraalVM native image offer over the traditional JVM-based approach?

GraalVM native image offers several advantages, including eliminating VM initialization and JIT compilation, which dramatically reduces startup time, and also reduces memory consumption by removing the memory footprint associated with VM.

How does the native image building process work according to the talk?

The native image building process takes classes and bytecode as input and compiles them into operating system-specific native images. It involves point-to-point analysis to collect necessary information, class initialization, and snapshotting, which are all included in the final native image.

What are the impacts that GraalVM has brought to the Java ecosystem as mentioned in the talk?

GraalVM impacts the Java ecosystem by no longer fully supporting dynamic features such as reflection, dynamic class loading, and dynamic processing. It also affects platform independence and the functionality of Java agents used for observability, which may not work under GraalVM native image.

Can you explain the role of the 'pre-running phase' in the solution presented by the speakers?

The 'pre-running phase' is an important part of the solution where the application executes with the otel Java agent and the Native image agent. The otel Java agent transforms classes, while the Native image agent collects transformed classes for further processing.

What is the purpose of the Native image agent as discussed in the talk?

The Native image agent is used to scan the application and gather all dynamic configurations. It helps to collect transformed classes directly and also to handle dynamic features in GraalVM such as reflection or dynamic proxies.

What are the two methods introduced to apply transformed classes in the talk?

The two methods introduced to apply transformed classes are 'class pass' and 'module pass'. Class pass involves defining transformed classes at the beginning of classpath, while module pass is similar but operates at the module level.

What did the demonstration in the talk show regarding the startup speed and data collection?

The demonstration showed that after applying the pre-running and static compilation phases, the startup speed increased significantly, and data collection by the Java agent was complete, including metrics, traces, and span attributes.

What are the future works mentioned by the speakers regarding the presented solution?

The future works include conducting more comprehensive tests over multiple signals like metrics and logs, and combining the pre-running phase and the static compilation phase into one phase to improve efficiency and maturity of the solution.

Is the presented practice currently being used in production?

No, the practice is not yet in production use. It is a preliminary result that requires further testing and maturity before being put into production.

Can the proposed solution be integrated into the OT Lambda layer?

The speakers are currently cooperating with the Serverless product team to integrate this solution into the product, aiming to benefit small applications with faster startup and quicker scale-out times.

Is there any change in response time between the GraalVM approach and the traditional VM approach?

The speakers did not observe any difference in response time between the two approaches. The main advantage of the GraalVM approach lies in reduced CPU and memory overhead.