AI-Powered Dragonwell Native Acceleration: Automatic Discovery of 10x Performance Improvement Opportunities

This article introduces an AI-powered performance analytics system that automatically identifies optimization opportunities in Java/Scala applications

By Lin Ziyi

Every performance optimization engineer's frustration is the same: having mastered exceptional skills, yet struggling to find the real enemy — performance bottlenecks. In practice, most time is spent locating bottlenecks and building appropriate performance tests. Once the problem is pinpointed, the fix is often completed quickly. Therefore, accurately detecting performance bottlenecks is the core pain point of efficient performance optimization.

Can AI help us automatically find these hidden bottlenecks and guide precise performance improvements? To answer this question, we developed a general-purpose AI-driven App Performance Analytics system and validated it using Apache Spark as a typical case. The evaluation shows that the method is valid: functions identified by AI as optimizable achieved up to 10x performance improvement in JMH tests after applying Dragonwell's Native acceleration technology. In TPC-DS end-to-end tests, combined with existing optimizations, overall performance improved by up to 9.69%. Spark's Native-optimized functions have been released in the latest Dragonwell version.

Traditional Flow of Performance Bottleneck Analysis and Its Challenges

Currently, developers typically follow a three-step flow to analyze performance bottlenecks:

· Collect hot data: In Java projects, tools such as AsyncProfiler are commonly used to collect runtime data and generate flame graphs and binary files in JFR (Java Flight Recorder) format. Developers rely on experience to detect potential bottleneck functions from the flame graph.

· Code Review: Go back to the source code to check why the function has a long execution duration and whether there is room for optimization.

· Verify or Backoff: If an optimization point is found, implement and authenticate it; otherwise, return to the flame graph to find the next candidate.

This flow is highly dependent on human experience and extremely time-consuming. This raises the question: can we feed flame graph data and source code directly to AI and let it automatically filter out candidate functions worth optimizing?

However, to assess whether AI is up to the task, you must first understand the scale of the problem. Taking Spark 4.0 running the TPC-DS benchmark test as an example, the problem space for optimization analysis is extremely large:

· 2,254 JFR flame graph files: TPC-DS contains 103 queries running on 3 distributed nodes. Multiple Java processes are started in each node, and each process generates a JFR file, totaling 2,254. Each file contains approximately 80,000 function samplings.

· 280,000 lines of code: The Spark 4.0 codebase contains approximately 270,000 lines of Scala and 10,000 lines of Java code, from which bottleneck functions and their context must be located.

· Function optimization assessment: Determine whether each candidate function has practical optimization value.

In this complex problem space, the third job — determining whether a function can be optimized — is where AI excels. The second (understanding code context) is also well handled by AI. However, the first (fetching key info from massive binary data) is far from the strength of current LLMs. Therefore, we must design a workflow that leverages AI's strengths while avoiding its weaknesses, letting AI focus on what it does best and using traditional tools to handle structured, high-throughput data processing jobs.

Workflow Design: Collaborative Architecture of Traditional Tools and AI

To this end, we built an intelligent App Performance Analytics optimization system as shown in the figure below. The system takes the Code Repository and JFR file directory of any Java/Scala project as input and outputs a structured optimization analysis report.

The core of the system is a deterministic analysis workflow with clear flow. We chose to implement this flow using a program rather than a Skill, because the trigger conditions for each step are well-defined and the logic is fixed. Code implementation is not only faster and more stable, but also avoids unnecessary LLM token consumption.

Strengths of tools: fast, stable, and reliable

AI is powerful but not omnipotent. Only through deep collaboration with traditional tools can AI focus on core jobs and maximize its effectiveness. To this end, we developed two key collaboration tools for AI to invoke:

· JFR Hot Spot Analysis Tool: Aggregates hundreds of JFR files to generate a global hot spot summary and extract a list of top N hot spot functions, eliminating the need for the LLM to process raw binary data.

· AST-based Function Query Tool: Parses source code to build an abstract syntax tree (AST), precisely locating and returning the complete definition and context of the objective function. More accurate and robust than simple grep search.

These two tools effectively shield AI from basic data processing and blur text-matching issues it struggles with, reduce the amount of context AI needs to work with, and allow it to maintain focus on optimization analysis.

This "each to their own" collaboration philosophy runs through the entire system design. Initially, we tried to leave all jobs to AI, but soon found it was unstable on certain structured jobs. For example, when determining whether a function is synchronized, AI would mistakenly search for the keyword globally in the file, leading to misjudgment. We therefore separated such jobs and implemented them in deterministic code, significantly improving the system's accuracy and reliability.

Strengths of AI: Semantic Understanding and Intent Recognition - Native Acceleration Optimization as an Example

Dragonwell 21 introduces a technique called "Native Acceleration Optimization" that can improve specific function performance by up to 10x. The principle is to bypass some of the JVM overhead and directly invoke highly optimized native assembly implementations. However, this also introduces strict security constraints — only functions that meet specific conditions can safely enable this optimization. Typical examples include:

· No object escape: Newly created internal instances cannot escape the scope of the function through return values or setting global variables. This would cause complex interactions between native memory and JVM memory, which Native Acceleration Optimization does not handle.

· No exceptions: The function cannot throw exceptions. Native Acceleration Optimization does not implement an exception handling mechanism.

Beyond safety constraints, optimization opportunities must also exist within the function to justify implementation, such as:

· The function's assembly code cannot be too short: If the function has very few assembly code instructions, the JDK's Just-in-time (JIT) compiled code is already good enough.

· Functions are compute-intensive: Compute-intensive functions have significant room for compilation optimization, while IO operations and object instantiation operations have no room for optimization.

· Other optimization opportunities exist: for example, eliminating If branch, using vector instructions, and other opportunities to apply faster semantic optimizations while keeping function inputs and outputs unchanged.

Traditional static analysis can hardly perform the safty and necessity checks described above, and relying on manual execution of these checks is like finding a needle in a haystack. However, analyzing these aspects is precisely where Large Language Models (LLMs) excel. We designed three dedicated AI Agents for this purpose:

· Escape Analysis Agent: Compared with complex traditional pointer analysis, an LLM can quickly determine whether an object escapes based on code semantics. This approach is simple to implement and delivers good results.

· Exception Analysis Agent: The difficulty of exception analysis lies not in detecting whether an explicit throw exists in the code, but in determining whether the behavior of throwing an exception is on an unreachable path, meaning no exception is actually thrown. For example, does the getSize function on line15 in the following code throw an exception? On the surface, the default case of the switch statement on line16 throws an exception. However, careful analysis shows that in the production environment, getUaoSize on row 16 can only return 4 or 8 and no other value, so the default case is unreachable. Traditional static analysis can hardly analyze the intent of this code, but an LLM can understand the code intent and derive from the context that no exception will be thrown.

private staticfinalint UAO_SIZE = Platform.unaligned() ? 4 : 8;  
  
privatestaticint TEST_UAO_SIZE = 0;  
  
_// used for test only  
_public static void setUaoSize(int size) {  
   assert size == 0 || size == 4 || size == 8;  
   TEST_UAO_SIZE = size;  
  }  
  
public static int getUaoSize() {  
   return TEST_UAO_SIZE == 0 ? UAO_SIZE : TEST_UAO_SIZE;  
  }  
  
public static int getSize(Object object, long offset) {  
   returnswitch (getUaoSize()) {  
    case4 -> Platform.getInt(object, offset);  
    case8 -> (int) Platform.getLong(object, offset);  
    default ->  
     _// checkstyle.off: RegexpSinglelineJava  
__ __ __ __  _thrownew AssertionError("Illegal UAO_SIZE");  
     _// checkstyle.on: RegexpSinglelineJava_  
   };  
  }

· Optimization Opportunity Analysis Agent: An LLM can not only discover optimization opportunities but also leverage context to uncover issues that humans tend to overlook. For example, for the following function, we had manually reviewed it before but never carefully examined the array on line 1 through 20. When facing such complex data, the human instinct is to skip over it. However, the LLM told us that simply replacing the 0s in this array with 1s would allow the ternary conditional operation on line 28 to be replaced with a direct array element read, thus achieving optimization. Furthermore, changing the byte array to an int array would also eliminate the overhead of sign extension operations from byte to int.

private staticbyte[] bytesOfCodePointInUTF8 = {  
   1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, _// 0x00..0x0F  
__ __  _1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, _// 0x10..0x1F  
__ __  _1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, _// 0x20..0x2F  
__ __  _1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, _// 0x30..0x3F  
__ __  _1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, _// 0x40..0x4F  
__ __  _1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, _// 0x50..0x5F  
__ __  _1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, _// 0x60..0x6F  
__ __  _1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, _// 0x70..0x7F  
__ __  __// Continuation bytes cannot appear as the first byte  
__ __  _0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, _// 0x80..0x8F  
__ __  _0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, _// 0x90..0x9F  
__ __  _0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, _// 0xA0..0xAF  
__ __  _0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, _// 0xB0..0xBF  
__ __  _0, 0, _// 0xC0..0xC1 - disallowed in UTF-8  
__ __  _2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, _// 0xC2..0xCF  
__ __  _2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, _// 0xD0..0xDF  
__ __  _3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, _// 0xE0..0xEF  
__ __  _4, 4, 4, 4, 4, _// 0xF0..0xF4  
__ __  _0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0_// 0xF5..0xFF - disallowed in UTF-8_  
  };  
  
...  

public static int numBytesForFirstByte(final byte b) {  
   finalint offset = b & 0xFF;  
   byte numBytes = bytesOfCodePointInUTF8[offset];  
   return (numBytes == 0) ? 1: numBytes; _// Skip the first byte disallowed in UTF-8_  
}

Through the collaboration of these AI agents, the system can efficiently and accurately evaluate whether a function is suitable for native acceleration optimization.

Effect: Significant improvement from function to end-to-end

The performance optimization analysis system takes the Spark code repository and 2,000+ JFR files as input, analyzes the hottest 400 functions (200 Spark functions and 200 JDK functions), takes 3 hours and 21 minutes, and successfully detects 34 functions with native acceleration optimization potential.

Considering developer cost, we selected two typical functions for optimization. The test results on Dragonwell 21 are as follows:

Function	Thread hotness	Process hotness	Global hotness	JMH Test Single Function Optimization
org.apache.spark.unsafe.map.BytesToBytesMap.safeLookup(Ljava/lang/Object;JILorg/apache/spark/unsafe/map/BytesToBytesMap$Location;I)V	13.71%	12.66%	2.98%	59.74%
org.apache.spark.unsafe.types.UTF8String.numChars()I	8.77%	7.59%	1.08%	1063%

Thread hotness: the hotness of execution in a single thread. Some functions have high global hotness but low thread hotness, indicating that the function running time is diluted by a large number of parallel threads. Such functions are not performance bottlenecks.

Process hotness: the hotness in a single process. For TPCDS tests, this is the hotness in a single query.

Global hotness: the overall hotness after merging all JFR files. For TPCDS tests, this is the hotness across all queries as a whole.

In the end-to-end test of all TPC-DS queries, the optimization results are significant:

· Dragonwell 21 + Native accelerated optimization improves performance by 5.7% compared with OpenJDK 21, of which AI-discovered optimization contributes approximately 2.2%.

· Dragonwell 11 + Native acceleration optimization improves performance by 9.69% compared with OpenJDK 11, of which AI-discovered optimization contributes about 4%.

· Dragonwell 8 + Native acceleration optimization improves performance by 6.11% compared with OpenJDK 8, of which AI-discovered optimization contributes about 2.5%.

The end-to-end test environment is:

· Distributed nodes: one master and three workers.

· CPU: AMD EPYC 9T24, master with 8 cores, worker with 32 cores.

· Memory: 32 GB for master, 128 GB for worker.

Next: Deepening AI Capabilities and Closing the Automation Loop

Based on the current results, we schedule to continue advancing in the following directions:

· Expand optimization analysis dimensions: Develop more types of AI agents to cover a wider range of optimization scenarios. For example, compare the performance differences of JDKs from different vendors under the same payload to automatically discover compilation optimization opportunities for Dragonwell, and explore Java code optimization opportunities with looser conditions that require only Java code modifications to implement.

· Build an end-to-end automated pipeline: Connect performance sampling, hot spot detection, AI analysis, optimization suggestion generation, automatic patching, regression testing, and effect verification into an "analysis-optimization-verification" loop. The future goal is to achieve "one-click performance tuning" and significantly reduce the cost of manual intervention.

Summary

This article reveals two key insights:

First, AI collaborates with traditional tools rather than replacing them. Performance optimization is a complex system engineering task. It includes structured, high-throughput data processing jobs (such as JFR aggregation and AST parsing), as well as judgment tasks that are highly dependent on semantic understanding (such as escape analysis and exception reachability). By delegating the former to efficient and stable traditional tools and the latter to AI for focused analysis, we can achieve a win-win in both efficiency and accuracy. It's not about "throwing everything to AI" — it's about "letting each widget do what it does best."

Second, AI delivers strong results in performance optimization analysis. Whether detecting Native acceleration opportunities or uncovering hidden code optimization points, AI demonstrates insight beyond human capability. Although the current system has achieved significant gains, many manual steps remain. The next step is to enable end-to-end automation, evolving AI-driven performance optimization from a "supporting tool" into "standard infrastructure."

With the assistance of AI, the optimization capabilities unique to Dragonwell 21 have been amplified, extending the optimization scope to positions previously difficult to reach through manual effort and achieving better optimization effects. The Spark Native optimization functions described in this article have been released in the latest versions of Dragonwell 21, 11, and 8 (Alibaba_Dragonwell_Extended_21.0.10.0.10+7, Alibaba_Dragonwell_Extended_11.0.30.27.7, Alibaba_Dragonwell_Extended_8.28.27).

For usage details, refer to: https://github.com/dragonwell-project/dragonwell21/wiki/Dragonwell-21-AI%E2%80%90Extension-%E7%94%A8%E6%88%B7%E6%8C%87%E5%8D%97

Community

AI-Powered Dragonwell Native Acceleration: Automatic Discovery of 10x Performance Improvement Opportunities

Traditional Flow of Performance Bottleneck Analysis and Its Challenges

Workflow Design: Collaborative Architecture of Traditional Tools and AI

Strengths of tools: fast, stable, and reliable

Strengths of AI: Semantic Understanding and Intent Recognition - Native Acceleration Optimization as an Example

Effect: Significant improvement from function to end-to-end

Next: Deepening AI Capabilities and Closing the Automation Loop

Summary

Read previous post:

Read next post:

OpenAnolis

You may also like

Comments

OpenAnolis

Related Products

Alibaba Cloud Model Studio

Message Queue for Apache Kafka

Qwen

Realtime Compute for Apache Flink