Introduction

trivago is one of the world’s largest hotel search platforms, processing billions of daily price, availability, and hotel records to provide the best options across 5 million+ accommodations in 190+ countries. At that scale, reliability and performance are of great importance.

Their GraphQL Gateway is the single entry point for all web and native app traffic across 48 microservices. For a long time, every deployment came with a tax: JVM warm-up caused timeout spikes and slow first requests — a frustrating but widely common issue. trivago’s team decided not to accept it. They migrated the GraphQL microservices to GraalVM Native Image, eliminating warm-up entirely and cutting one service from 43 replicas down to 12 and CPU usage from 15 cores to 5.

We asked trivago’s team members, Hans Puac, Backend Software Engineering Lead, and Ayush Chaubey, Backend Software Engineer, to tell us more about the migration process and share their insights with our community.

Background

Can you briefly describe the GraphQL Gateway — its tech stack traffic volumes, and why it is central to trivago’s infrastructure?

A bit of history: trivago switched from JSON REST APIs to a GraphQL endpoint in 2019 to address versioning challenges, give clients more flexibility when fetching and aggregating data, and reduce overfetching. We initially started with a monolithic GraphQL server, which eventually hit performance limits.

Today, we run a federated GraphQL architecture: all GraphQL requests first hit a Rust-based gateway using the Apollo Router, which acts as the central entry point and orchestrates calls to the services behind it. Our graph is split into 40+ subgraphs. These subgraphs run on the JVM or GraalVM (Java 25), use Spring Boot, and implement GraphQL via Netflix DGS. The codebase is written in Kotlin, built with Gradle, and deployed through CI/CD pipelines to GCP.

Traffic volume varies significantly across subgraphs. For example, during peak traffic in a single region, our translations subgraph exceeds 9,000 requests per second.

The GraphQL Gateway is central to trivago’s infrastructure because it provides a single, unified interface for all clients (web and native apps) to query the data they need. You can find out more about it in trivago’s engineering blog.

Before GraalVM, did you try other ways to reduce warm-up time before deciding to explore Native Image?

Before exploring GraalVM Native Image, we tried several approaches to reduce warm-up time.

For example, we developed a custom class loader to eagerly load many commonly used classes right after the application starts. We also added a startup routine where the service triggers an HTTP call to itself, so the web server initializes thread pools and other internal components early. In addition, we adjusted our rollout strategy on GCP to ramp traffic up gradually on new pods, rather than sending them full peak RPS immediately.

Discovering GraalVM

How did your team first learn about GraalVM and decide to use it?

GraalVM first came onto our radar in early 2021 through blog posts, such as one on the Spring blog. At the time, we created a time-boxed investigation task, but it ended up sitting in the backlog until 2023. That year, two of our developers attended the Spring I/O conference, where GraalVM was highlighted in the keynote, which brought the topic back into focus.

For a long time, our SREs had been dealing with the JVM’s warm-up behavior, especially slow first requests after startup. GraalVM promised improvements there, so we decided to validate it with a proof-of-concept.

At trivago, one of our core values is the “power of proof”, so we aimed to migrate a single service first and run a side-by-side comparison against the JVM version before committing further. To keep the initial effort low, we accepted a few shortcuts during the tryout, for example, building the native binary on a developer machine, manually creating and deploying the container image, to gather real numbers. The main requirement was that the GraalVM build behaved identically to the JVM version.

Once we saw the initial results, we committed to adopting it properly across the codebase, including the necessary changes to our CI/CD setup.

Migration

Can you briefly walk us through the first migration, including the thought process and lessons learned?

Our first migration focused on a smaller service that wasn’t heavily tied to external dependencies and was less complex, making it a good candidate for early migration.

Here’s how the journey unfolded:

• Native Image Build Issues. We quickly discovered that some of our core frameworks and libraries weren’t fully compatible with GraalVM Native Image. That meant either contributing fixes upstream in open source or finding alternative, compatible libraries. For example, when we ran into compatibility issues with Netflix DGS, we addressed them through small upstream contributions, like this change to make reflection work and this change to ensure certain classes are set up in the way GraalVM requires. These contributions helped enable GraalVM Native Image support. On top of that, we hit build-time exceptions related to class initialization order. The error messages often suggested whether a class should be initialized at build time or at runtime, but getting it right still required several build–test–repeat cycles.
• Logging Framework Switch. Our initial use of Log4j posed a challenge, as it was not compatible with GraalVM native images. To resolve this, we transitioned to Logback, which integrates seamlessly with native images and ensured continued smooth logging across our services.
• Testing Framework Adjustments. Our test suites previously leaned heavily on Mockk, but since GraalVM native images don't support dynamic mocking, we shifted many tests to use technologies like Testcontainers. In scenarios where mocking was essential, we disabled those tests during native image builds using the @DisabledInAotMode annotation.
• Runtime Errors. Even after a successful build, we faced runtime exceptions — mainly because GraalVM’s static analysis missed some classes used reflectively. We addressed this by using Spring’s RuntimeHintsRegistrar API to explicitly register Runtime hints, and leveraging GraalVM’s tracing agent during tests to automatically discover and register necessary classes.

Key Learnings:

• Start with less complex services when starting with GraalVM native image.
• Prepare for hands-on debugging, as fixes often require several iterations.
• Invest time in automated tests — tools like the tracing agent rely heavily on robust test coverage.
• Community engagement (open-source contribution) can sometimes be the fastest path to long-term solutions.

Did the migration become easier over time, for example when migrating service #14 compared with service #1?

Yes, migrating later services became significantly easier compared to our initial efforts. By the time we reached service #14, we had established a robust framework for managing custom hints and had streamlined our build process. Our growing familiarity with GraalVM’s configuration options and performance tuning flags allowed us to optimize native images more effectively, right from the start. The lessons learned and best practices developed early on translated into faster, smoother migrations for subsequent services.

What changes, if any, were needed in your CI/CD pipeline and test strategy to support Native Image builds?

To support Native Image builds, we had to make a few practical changes to our CI/CD pipeline compared to our standard JVM setup.

First, the build stage needed more powerful builders/runners. Native Image compilation is significantly more resource-intensive and requires much more RAM than a regular JVM build, so we adjusted our CI machine sizing accordingly. To keep feedback cycles fast, we also differentiate build modes: PR preview builds use GraalVM’s faster -Ob quick-build mode, while production builds run with -O3 for maximum performance.

Second, our container build process changed. For JVM services we previously built images with Jib, but for Native Image we had to package the generated binary into a Docker image ourselves as part of the pipeline.

We also used a distroless base image, which meant we had to explicitly add a few runtime dependencies that were previously available implicitly. For example, we had to include aarch64-linux-gnu/libz.so.1 ourselves.

Finally, architecture mattered more: Native Image builds are tied to the target platform. We originally built on amd64, but since we now run on arm64, we also had to build on arm64 in CI. With JVM-based services, multi-arch images are much easier to produce because the same artifact can typically run across architectures.

The Results

The numbers you shared (43 → 12 replicas, 15 → 5 CPU cores) are really impressive. Can you share some benchmarks or performance measurements?

Since this migration happened a while ago, we only have a few screenshots from that time rather than a complete set of benchmarks.

In the first screenshot, you can see the replicas regularly maxing out before the change, and then dropping significantly after the release.

Because some deployments are assigned only a fraction of a CPU core, we also built a dashboard panel that normalizes throughput by CPU: requests handled per full CPU core. That metric increased substantially after the migration.

The second screenshot shows the impact on heap usage. The top panel contains the “classic” JVM heap metric we used before the migration, so it stops at the point where we switched the service to Native Image. The lower panel shows our replacement metric (“MXBean JVM Heap”), which we introduced afterwards and which continues to report heap usage for the native build.

A couple of caveats: the values shown are aggregated averages across multiple pods, not a single instance. Even with that in mind, the reduction is still clearly visible. Overall heap usage dropped significantly after the migration.

This chart also highlights an observability detail we’ll mention later: with Native Image we initially lost some of the heap/JVM metrics we previously got automatically, so we had to collect and expose parts of them ourselves.

Were there any unexpected benefits or trade-offs that you didn’t anticipate going in?

While we anticipated faster start-up times and reduced memory usage after migrating to GraalVM native image, the process yielded a few additional surprises:

Unexpected Benefits:

• Lower CPU Utilization: Beyond our baseline expectations, we observed a noticeable decrease in CPU usage. This allowed us to reduce CPU core allocations for most services, translating to both cost and resource savings.
• Smaller Image Size: The resulting native images were much leaner and took up less storage space, which was a welcome side effect for deployments and distribution.

Unexpected Trade-offs:

• Longer Build Times: Building native images took significantly longer than standard JVM builds. While the increased build time was the most noticeable trade-off, it was manageable within our CI/CD pipelines given the substantial runtime performance improvements. Importantly, this does not impact day-to-day development: developers typically run the JVM version locally, and PR preview builds use GraalVM’s faster -Ob quick-build mode.
• Additional Configuration Effort: Another challenge was the need to provide custom runtime hints and rely heavily on GraalVM’s tracing agent to achieve comprehensive coverage of code path — especially for reflective operations. This required additional effort during both development and testing.

We often get questions about observability and monitoring of native images. Can you share what you use in your system?

We use largely the same observability stack as before. Most metrics are exposed out of the box via Spring Boot with Micrometer and the Prometheus exporter, and we complement those with custom application metrics.

One change was needed for services built with GraalVM Native Image: we no longer got the usual JVM heap/memory, GC, and thread metrics that were available on the JVM. To compensate, we added our own metrics based on the MemoryMXBean, PlatformMXBean, and ThreadMXBean.

It was also helpful to enable com.sun.management.jmxremote for the GraalVM builds. That allowed us to inspect live pod metrics at higher resolution using tools like VisualVM.

Future Plans

You still have 34 services to go. How are you prioritizing the next migrations, and do you have any other future plans related to this?

After migrating the highest-traffic and highest-impact services, we’re continuing with the same approach we’ve had from the start: prioritizing what makes the most sense to migrate next, based on impact and effort, not speed for its own sake.

Recently, we completed and rolled out the Java 21 → 25 upgrade so we could take advantage of GraalVM’s -O3 optimization, which is now running in production. Next, we're planning the Spring Boot 4 and DGS 11 upgrades. We also want to re-evaluate GraalVM PGO (profile-guided optimization): in earlier tests it delivered promising results, but it requires additional work to collect and store the generated profiles in a reliable way.

For the remaining services, we’re prioritizing migrations opportunistically, for example, when a service is already undergoing a larger refactor or other significant changes, we’ll often migrate it to Native Image as part of that work. We also move a service up the list when we see a clear performance or cost issue that Native Image can help with. The long-term goal is still a full migration, but at a slower, pragmatic pace.

Are you exploring other GraalVM capabilities beyond Native Image, such as integrations for Python, JavaScript, or WebAssembly?

It’s definitely an interesting part of GraalVM, but so far we haven’t had a concrete use case for it. Right now, our focus remains on Native Image.

Conclusions

What advice and resources would you share with teams looking to adopt GraalVM Native Image?

A German saying we like is: “Probieren geht über Studieren.” Roughly translated, it means “Trying beats studying.” Online benchmarks can be helpful, but it’s hard to know how well they will translate to your own codebase and production workloads. Our recommendation is to build a small MVP first, just like we did, to evaluate whether the benefits of GraalVM Native Image justify the cost and effort. And it’s perfectly fine to take shortcuts at this stage, the goal is learning. Get an MVP running, compare it side by side with your JVM version, and then decide how to proceed.

Be prepared for a learning curve: it takes time to understand GraalVM’s closed-world principle, reflection/type hints, the build process, and tools like the tracing agent. We also noticed that AI tools still often struggle to interpret and debug GraalVM error messages, so it helps to fall back on classic debugging practices: isolate the problem, narrow it down, and change one thing at a time. Often you’ll encounter a chain of issues that need to be resolved step by step, so don’t let frustration win. The payoff can be significant, as our results show.

Inside trivago’s GraalVM Migration: Native Image for GraphQL at Scale was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nowadays AI provides many great features, from quick answers to smarter search and digital assistants.

In this blog post, we’ll build a Swiss travel assistant that understands user intent. When a user asks something like:“Provide recommendations for a peaceful mountain resort”, the application will embed the query, run vector similarity search in the database, and return destinations that mean the right thing — even if they don’t contain the exact words. This enables more advanced and rich search user experience.

We’ll use:

• Micronaut 4 — lightweight JVM framework with compile-time dependency injection
• LangChain4j — a library for LLM orchestration and tool calling
• Oracle AI Database — native vector storage and similarity search
• OpenAI — an LLM for covering chat and embeddings

Project details

Here’s what we will build:

• A web app that exposes a /api/chat endpoint
• On startup, it loads a dataset with travel destinations, hotels, activities
• Each entry gets a vector embedding generated from its description
• Vectors are stored in Oracle Database next to the application data
• At query time, we embed the user question the same way, and run similarity search
• The LLM proposes which tools to call, while LangChain4j handles execution and message routing.

Micronaut: fast by design

First, let’s briefly look at Micronaut in case you are new to it.

Micronaut is a JVM framework for building modern lightweight applications. It was introduced way back in October 2018 — you can still find Graeme Rocher’s talk presenting it.

The key idea behind Micronaut is shifting dependency injection and annotation processing to compile time instead of runtime. Why? Traditionally, many frameworks heavily relied on reflection to scan application classes and resolve dependencies upon application start. Such approach often ended up being time- and memory consuming. Micronaut moves all of that work to build time — your app starts with everything already wired up. If you are familiar with the key idea behind GraalVM Native Image, you will find this quite similar: shift work to the build time, so you can start instantaneously when it actually matters: at run time.

The performance outcomes of shifting to build time:

• Sub-second startup times on the JVM
• With Native Image, apps can run with as little as a 10MB heap!
• Less reflection makes native compilation fast and easy out of the box
• On top of that, reduced reflection means better performance and smaller binaries.

So the idea behind Micronaut is to provide a great developer experience and performance at no runtime cost.

Now, let’s look at some of the key concepts of Micronaut.

If you know Spring, many things in Micronaut will look familiar. The programming model is similar — annotations, constructor injection, controllers, and configuration properties work the same way.

Compile-Time Dependency Injection

When you annotate a class with @Singleton or @Controller, the annotation processor generates the injection logic during compilation, with no need for run-time reflection.

As the result, missing dependencies fail at compile time rather than at startup, and the generated code is plain Java code that compilers know how to inline and optimize.

As an example, here’s what your hello world application could look like:

import io.micronaut.http.annotation.Controller;
import io.micronaut.http.annotation.Get;

@Controller("/hello")
public class HelloController {

    @Get
    public String hello() {
        return "Hello, World!";
    }
}

From annotation processing at compile time comes one distinct quality of Micronaut: when adding Micronaut modules, you often need to include both the library dependency and its corresponding annotation processor. For example, adding LangChain4j support means adding both micronaut-langchain4j and micronaut-langchain4j-processor. The processor will take care of generating the necessary code.

Standard Annotations

Micronaut implements the JSR-330 dependency injection standard. You can use standard jakarta.inject annotations like @Inject and @Singleton. In addition to familiarity, this makes it easy to write framework-agnostic code and share libraries across projects.

Compile-Time Aspect-Oriented Programming

Aspect-oriented programming in Micronaut also happens at compile time. Interceptors are integrated into your code during compilation, avoiding the runtime proxy generation. This means AOP features like @Cacheable, @Transactional, and custom interceptors work without reflection overhead.

GraalVM Native Image Support

Micronaut was designed with GraalVM and AOT compilation in mind. Since all dependency injection and AOP happens at compile time, there’s little to no reflection in the framework to configure for Native Image compilation.

Together with Micronaut’s compile-time approach, Native Image allows applications to start in milliseconds, use a fraction of the memory, and ship as self-contained executables without requiring a JVM installation.

Polyglot Support

Interestingly, Micronaut is also no stranger to polyglot programming. It supports Java, Kotlin, and Groovy, with features and annotation processing working across the languages.

Micronaut also offers first-class support for Graal Languages, such as GraalPy (see the example), but that's a story for another time.

LangChain4j: Bringing LLMs to Java

Now let’s look at LangChain4j, an open-source library that will take care of AI orchestration in our project.

It provides:

• Chat models (OpenAI, Anthropic, Mistral, etc.)
• Tool calling (function calling) with structured arguments
• Chat memory
• RAG features (embedding models and vector stores)
• Framework integrations (Micronaut/Spring/Quarkus).

Now, let’s also look at the key building blocks of LangChain4j.

ChatModel

ChatModel is the common low-level API for interacting with LLMs, that you are probably familiar with. You build a ChatRequest containing ChatMessage objects and receive a ChatResponse with the model's reply and metadata. The message types include UserMessage for user input (which can be multimodal), SystemMessage for predefined instructions, and AiMessage representing the model's response.

AI Services: simple declarative approach

AI Service lets you define a Java interface and have LangChain4j generate the implementation:

import dev.langchain4j.service.SystemMessage;
import io.micronaut.langchain4j.annotation.AiService;

@AiService
public interface Assistant {

    @SystemMessage("You are a helpful travel assistant")
    String chat(String userMessage);
}

You then inject and call it like any other service, for example assistant.chat("Find me a hotel in Zurich"). Under the hood, LangChain4j will create a proxy that converts your method call into the appropriate UserMessage, adds the SystemMessage, calls the ChatModel, and extracts the response text.

AI Services can also handle chat memory, tool execution, structured output parsing, and RAG.

Chat Memory

ChatMemory automatically manages conversation history, with optional strategies for retaining recent messages.

For persistence beyond in-memory storage, you can implement the ChatMemoryStore interface, for example in Oracle Database.

Tools

Tools are predefined actions that can be invoked by the LLM. While this doesn’t sound too complicated, it’s a significant step forward from the early days of using LLMs in applications, when there was little to no determinism and control. Function calling provides structured outputs that match a defined schema, constrains the LLM to actions you’ve explicitly defined, and separates reasoning from execution, where the LLM decides what to do, but your code controls what actually happens.

Embedding Models and Stores (RAG)

For Retrieval-Augmented Generation (RAG), LangChain4j provides EmbeddingModel and EmbeddingStore abstractions, which we will use to supply our application with predefined data about travel destinations and activities and perform semantic search.

Micronaut and LangChain4j in action

Micronaut and LangChain4j together enable a nice declarative approach for extending Java applications with AI capabilities:

@AiService
public interface Assistant {
    @SystemMessage("You are a helpful assistant")
    String chat(@UserMessage String message);
}

That can be further injected:

@Inject Assistant assistant;
assistant.chat("What should I see in Zurich?");

The implementation will be generated at compile time by micronaut-langchain4j-processor.

Similarly, we can create tools for our travel assistant:

@Singleton
public class TravelTools {

    @Tool("""
        Search for Swiss destinations. Use for location queries.
        """)
    public List<Destination> searchDestinations(String query) {
        float[] embedding = embeddingService.embed(query);
        return destinationRepository.searchByVector(embedding, 5);
    }
}

In this case LangChain4j will handle the function calling protocol with OpenAI: converting the method signature to a JSON schema, parsing the LLM’s function call response, invoking the method, and feeding the results back.

Vector Search with Oracle Database

Oracle AI Database supports native vector columns, so you can store embeddings alongside regular relational data. In our schema, all entity tables — destinations, hotels, and activities — include a description_embedding column: a 1536-dimensional vector, matching the output of OpenAI’s text-embedding-3-small model.

When a user sends a request, the application embeds that query and passes the resulting vector to the database. Oracle’s VECTOR_DISTANCE function evaluates cosine distance and orders results by similarity, returning the top matches.

On startup, the app checks for entries without embeddings and generates them automatically, persisting them in the database for future queries.

GraalVM Native Image for performance and efficiency

Micronaut’s compile-time approach works great with GraalVM Native Image. Building, deploying, and running such native executables is straightforward:

./mvnw package -Dpackaging=native-image
./target/swiss-travel-advisor

The resulting image:

• Has the size of 132 MB 📦
• Starts and connects to the database in 122 ms 🤯
• Even under load, consumes only around 98 MB RAM! 🚀

Bringing everything together

You can follow the steps below, or get the complete example on GitHub.

First, let’s start our database. You can use Docker or Podman:

podman run -d -p 1521:1521 --name travel-app-db \
  -e ORACLE_PASSWORD=mypassword \
  -e APP_USER=appuser \
  -e APP_USER_PASSWORD=mypassword \
  gvenzl/oracle-free:latest

Once that’s ready (and your OPENAI_API_KEY is set), start the app:

export OPENAI_API_KEY=your-key
./target/swiss-travel-advisor

This starts the application and populates the database with our predefined data. Flyway runs the migration scripts on startup, creating tables and inserting the destinations, hotels, and activities. Once the server is running, the DataInitializer generates vector embeddings, enabling semantic search.

Now for the fun part — let’s ask our assistant for travel recommendations. I can highly recommend using httpie:

http POST http://localhost:8080/api/chat message="recommend best ski resorts"

Here are some of the best ski resort destinations in Switzerland for you to consider:

1. St. Moritz (Graubünden)
   - Known for its glamorous vibe, luxury shopping, and winter sports.

2. Zermatt (Valais)
   - Charming alpine village at the foot of the iconic Matterhorn.

3. Interlaken (Bernese Oberland)
   - Adventure capital nestled between Lake Thun and Lake Brienz.

Would you like more information on any of these destinations? Let me know if you'd like to add any to your wishlist!

Notice how “best ski resorts” matched destinations based on meaning, not keywords — that’s vector search.

Our advisor also supports a wishlist feature, which is another Tool that the LLM can use. Let’s save Interlaken from the suggestions above:

http POST http://localhost:8080/api/chat message="add Interlaken to a wishlist"

Interlaken has been added to your wishlist! 🎉 You're going to love the adventure and stunning scenery there. Let me know if you need help with accommodations or activities in the area!

And we can retrieve it later:

http POST http://localhost:8080/api/chat message="retrieve my wishlist"

Here's your current wishlist:

- **Interlaken (Bernese Oberland)** 

If you'd like to add more destinations, hotels, or activities, just let me know!

In this case the LLM decides when to call tools and how to present the results — you just define the tools and rely on Micronaut and Langchain4j for any necessary code generation and other implementation details.

Conclusions

AI-powered assistants are a natural fit for recommendation apps. Users can ask questions in plain language — “recommend a cozy ski town” or “add this to my wishlist” — and the system will understand the intent, process the data, and act accordingly.

In this demo, Micronaut acts as a lightweight and efficient framework that is great for microservices and any applications where speed and memory usage matter. LangChain4j handles the AI orchestration, such as working with chat memory and tool calling. Oracle AI Database stores our vectors alongside application data, so we get convenient and powerful similarity search out of the box.

Together, these technologies offer a convenient way to build fast and smart Java applications. You can find the full project code and running instructions on GitHub, and learn more at graalvm.org and micronaut.io.

Building an AI Travel Assistant with GraalVM, Micronaut, and LangChain4j was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a guest blog post written by João Nogueira, a software engineer at Picnic Technologies.

At Picnic, we’re on a mission to deliver the freshest groceries right to our customers’ doors through a seamless mobile-only experience. As a rapidly scaling online grocery retailer, our success relies on the agility of our technology.

We faced a continuous challenge: how to rapidly evolve our mobile app’s user interface to meet evolving customer demands, deploy updates instantly, and empower non-engineers (like marketers or content managers) to contribute to the app’s dynamic content without requiring a new app release. Waiting for days or even weeks for users to update the app after every UI change was simply not scalable for our business.

Why Server-Driven UI is Our Strategy

To solve this, we adopted and developed a powerful Server-Driven UI (SDUI) framework: the Page Platform. SDUI became crucial for two main reasons:

1. Instant Deployment: It allows us to define and modify app screens in real-time. By shifting the responsibility for rendering logic from the client app to the server, we can deploy UI changes instantly, bypassing the lengthy app store review process and ensuring all users see the freshest content immediately.
2. Empowering Non-Engineers: The platform serves as a powerful abstraction layer, enabling teams across the business to create complex, data-driven content using simple configuration, effectively giving them the tools to design and control parts of the app experience without writing a single line of client-side code.

The Status Quo: Handlebars’ Limitations

Our initial approach to Server-Driven UI utilized Handlebars as a templating language within the Page Platform. While it offered a degree of configurability and allowed us to initially separate content from presentation, we quickly encountered its limitations:

• Rigid Syntax and Logic: Handlebars’ logic felt rigid and restrictive. As our pages grew more complex, we found its limited support for intricate logic made implementation difficult, often forcing us to rely on custom, Java-based helpers to execute simple business rules.
• Weak Tooling and Maintainability: Critically, Handlebars lacked the rich IDE support and type-safety we needed for production-grade code. This increased the friction for our engineers and made complex refactoring and maintenance challenging.
• Backend Integration: Critically, we needed a solution that could seamlessly integrate with our powerful Java backend, supporting Calcite queries (our query infrastructure that allows running SQL queries across all kinds of data sources) and other Java logic, while enabling more complex UI logic without relying solely on the Java ecosystem.

This set of challenges led us to seek a more flexible solution. The true innovation began when we sought a runtime solution that could bridge the gap between our robust Java backend and the modern, flexible JavaScript/TypeScript frontend technologies preferred for dynamic UI development. This pursuit led to a critical decision: how to efficiently and safely execute JavaScript directly within our existing Java application. This is where GraalVM became the cornerstone of our strategy, enabling a polyglot architecture that significantly streamlined our development and deployment.

Exploring Implementation Options

With JavaScript as our chosen language, the next challenge was deciding how to run it on the backend. We explored two main approaches:

Standalone JavaScript services

The most straightforward way to execute JavaScript on the server.

• Pros: Easy to set up, aligned with traditional JavaScript backend architectures.
• Cons: Introduced operational complexity — we would have to learn how to run JavaScript services in production at scale. Additionally, it lacked direct interoperability with Java, requiring more services and contracts, which added friction to the release process. Moreover, communication with our Java BE services would represent extra network communication.

Running JavaScript inside our Java application

A more integrated approach that would allow JavaScript execution within the JVM.

• Pros: Offers seamless interoperability with Java, eliminating the need for additional services to manage. This approach promised a more unified and efficient system.
• Cons: We lacked experience with this approach and weren’t sure how to implement it effectively.

Given the significant benefits of seamless interoperability and reduced operational overhead offered by running JavaScript inside our Java application, we chose to pursue this integrated approach. This decision set the stage for adopting a polyglot runtime that could effectively bridge our Java and JavaScript ecosystems.

Adopting GraalVM: Powering Polyglot Applications

As a polyglot virtual machine, GraalVM allows us to run multiple languages — including JavaScript — within the same Java runtime environment. By adopting GraalVM, we could execute JavaScript code seamlessly within our backend Java application, allowing for page templates defined in JavaScript to be evaluated in the JVM.

A critical requirement was ensuring safe interoperability between Java and JavaScript. Sharing Java objects directly with JavaScript can unintentionally expose internal methods and properties we don’t want to be accessible, as while we want to expose the fields of a certain Java object, the same doesn’t apply to common methods like `toString`. Instead of allowing unrestricted access to Java classes and methods, we crafted a custom API based on a promise-driven structure (supporting interoperability with asynchronous Java methods). Each page is represented as an async function, and we subscribe to this promise from Java, providing only the specific parameters required for each page render. To enable JavaScript to invoke certain asynchronous Java methods (data retrieval from Calcite being the clearer asynchronous use-case), we extended this promise-based API, allowing JavaScript to call back into Java in a controlled, asynchronous manner. This leveraged GraalVM’s built-in support for awaiting Java `CompletableFuture` objects from JavaScript, a key feature for handling asynchronous operations in a polyglot environment. By controlling this Java to JavaScript interaction, our setup is efficient, scalable, and extensible, giving us the benefits of JavaScript’s flexibility within the stability and performance of the Java backend.

Challenges we faced

Our use case required careful orchestration to ensure optimal performance. Each GraalVM context — a necessary component for executing JavaScript — can handle only one script execution at a time. A naive approach, where a new instance is created for every request, would fail to leverage GraalVM’s internal optimizations, significantly impacting execution performance.

Since creating new contexts is computationally expensive and their initial executions are slow due to the lack of runtime optimizations, we implemented an ObjectPool to efficiently manage and reuse them. This pooling mechanism allowed us to minimize the overhead of repeatedly instantiating contexts, instead recycling them to handle incoming executions more efficiently. This pooling strategy was vital for ensuring that our GraalVM-powered Page Platform could meet the stringent performance and scalability requirements of our production environment.

Page Rendering Flow: An Overview

Before diving into the specifics of our tooling, it’s important to step back and look at how our Page Platform operates at a high level. The process of rendering a page follows this general flow:

1. The app requests a page by its ID and relevant parameters.
2. This request is sent to our Java backend service.
3. The backend retrieves the corresponding JavaScript code for the requested page and executes it on the server using GraalVM.
4. During execution, the JavaScript code interacts with Java components as needed — for example, to fetch data using Calcite (our data retrieval API) or, in the future, to trigger side-effect-driven actions. GraalVM’s polyglot capabilities are crucial here, enabling seamless and efficient calls between JavaScript and Java.
5. Once all necessary data is retrieved, additional business logic expressed in JavaScript may be executed on the server within the GraalVM runtime.
6. The final output is a serialized JSON structure that adheres to a predefined contract describing how the page should be rendered. This response is passed back to the client via Java, completing the request/response cycle.

With this foundation in place, let’s explore how we bridge JavaScript and Java to make this process seamless.

Bridging JavaScript and Java

To define our pages in JavaScript and enable their execution within our Java backend, we needed to establish a clear contract. This contract, facilitated by GraalVM’s interoperability features, ensures that each page’s JavaScript execution produces a well-defined output that Java can efficiently process, generating the correct JSON response for the app.

To achieve this, we designed the following API:

• JavaScript exports a map of page IDs to asynchronous functions. Each function, when executed, resolves to a JavaScript object that adheres to the predefined Page API.
• Java provides an interoperability API, enabling JavaScript to invoke asynchronous Java methods when needed, securely bridging the two languages.

This setup, powered by GraalVM, ensures seamless communication between JavaScript and Java, allowing for efficient data retrieval, business logic execution, and page rendering directly within the JVM.

The JavaScript code executed in our system is version-controlled in a Git repository, ensuring that every change is tracked and represented by a unique Git revision. For each revision, a new JavaScript bundle is generated. This bundle is designed to adhere to a specific API, which we outline below (example of a `home-page` simply with a title section):

const Pages = {
  'home-page': async () => {
    return {
      title: "Home Page"
    }
  }
}

export default Pages;

Similarly, we had to establish a clear API that would allow developers to request data from Calcite queries directly within the JavaScript framework. This interaction had to align with our promise-driven infrastructure. To accomplish this, for each page rendered, we bind a query method to the GraalVM context, which delegates to the Calcite query resolution logic, effectively creating a bridge between the JavaScript and data query layers within the polyglot environment.

This approach enables seamless data retrieval, following a simple API structure, as shown below:

await query('SELECT * FROM table_name', {'parameter_key': 'parameter_value'})

This well-defined API not only enables seamless interaction between the JavaScript and Java layers in production (leveraging GraalVM) but also facilitates a streamlined local development environment. Using a local Node.js server, JavaScript developers and page authors can significantly shorten their feedback loop. In this setup, queries and invocations are routed to an internal REST endpoint, providing the necessary data for page rendering. It’s important to note that while Node.js provides a familiar environment for local development, the production environment relies on GraalVM to execute the JavaScript code directly within the JVM, ensuring the performance and interoperability benefits of our polyglot architecture.

JavaScript-Powered Templates: Leveraging Modern Frontend Practices within Java

Moving to JavaScript for templating was a significant upgrade, giving us the full power of a programming language to build server-side pages. To further enhance developer experience, maintainability, and reliability, we embraced TypeScript and JSX. Inspired by React’s JSX setup, we integrated this powerful, declarative syntax into our framework.

JSX allowed us to create reusable components with a clean, intuitive syntax and robust IDE support, including AI-powered suggestions. This choice brought us the benefits of type-safety, build-time validation, and a familiar development experience for frontend engineers.

A crucial step was ensuring our TypeScript and JSX setup was compatible with our production environment: GraalVM. Since GraalVM executes standard JavaScript, we configured our build process to transpile our TypeScript and JSX code into vanilla JavaScript with a single main entry point. This allowed us to leverage modern frontend development practices while seamlessly integrating and executing these dynamic templates directly within our Java backend via GraalVM.

Bundling: Preparing JavaScript for GraalVM Execution

To optimize our approach, we introduced a bundling process to generate production-ready bundles that seamlessly integrate with our backend. Bundling ensures compatibility with production environments, and we developed custom plugins to enable advanced functionality, such as importing SQL query files that transform SQL files into JavaScript functions, complete with support for dynamic parameters.

Additionally, we version each bundle output, allowing us to load specific versions of the code as needed. Having a bundler also gives us the flexibility to add new dependencies and include them in the bundle without impacting the backend system. This centralized approach makes dependency management much more efficient.

Testing

For testing, we used an infrastructure that supports parallel execution and integrates seamlessly with our bundling setup. This enables us to create test environments that closely mimic production. In addition to standard testing — such as unit, functional, performance, and snapshot tests — we developed custom tests tailored to our pages, including end-to-end (E2E) and visual regression tests. These ensure consistent behavior across different environments and help us catch issues early.

Development Server

To further streamline development, we set up a local development server and integrated our network proxy to capture and redirect application requests to the local implementation. Additionally, we reused the custom plugins from our bundling and testing setup to ensure that the dev server mimics the bundler’s behavior. This creates a consistent experience across development, testing, and production environments.

Our setup allows us to seamlessly switch between real and mocked data sources, providing flexibility for accurate and immediate testing. When mock data isn’t used, we implemented local versions of data providers to communicate with REST endpoints, effectively simulating our production environment. In production, however, API bridges between JavaScript and Java handle direct connections to our backend.

One key difference between our local and production environments is that GraalVM, which we use in production, provides a JavaScript runtime but lacks full Node.js functionality. This required us to account for certain limitations and ensure our setup remained compatible across both environments.

In conclusion, this comprehensive setup — featuring TypeScript, JSX, bundler, testing environment, and local development server — empowers us to develop, test, and deploy server-side pages with ease. With real-time feedback, production compatibility, and flexibility for complex logic, our approach simplifies the development process and reduces time to production, resulting in a highly maintainable and efficient system.

Deployment: Ensuring Consistent JavaScript Execution with GraalVM

As mentioned earlier, the JavaScript framework is version-controlled in Git, with each change corresponding to a new Git revision. To ensure our running environments stay up to date with the latest changes and that GraalVM always executes the correct version of our dynamic templates, we implemented a GitHub webhook that notifies our backend deployments of incoming updates. Upon receiving a notification, the backend fetches the latest changes from the repository, generates the updated JavaScript bundle, and replaces the deployed version with the newly committed code.

This process ensures that the latest revisions are seamlessly integrated into the environment, ready for GraalVM execution. The overall flow can be summarized as follows:

How resilient is our system, though? What happens if GitHub is down? Do we ensure our system can withstand third-party outages? This is where the Elastic File System (EFS), mentioned in the diagram above, comes into play.

But what exactly is an Elastic File System? As Amazon describes it:

“Amazon Elastic File System (Amazon EFS) provides serverless, fully elastic file storage, allowing you to share file data without provisioning or managing storage capacity and performance.” — source

So, how does this help? First, our backend application is deployed across multiple replicas. We don’t want each replica to depend on a live connection to GitHub to fetch its own version of the Git repository. To solve this, we store both the updated repository and the generated bundles in the Elastic File System. This shared EFS volume is accessible by all our application pods, ensuring that the GraalVM runtime on each replica can access the correct, up-to-date code.

In the event of a GitHub outage, not only do we have an up-to-date copy of the Git repository (as of the last successful update), but we also have the generated bundles stored in the EFS. This ensures that we avoid the overhead of regenerating bundles every time, and more importantly, it removes the direct dependency on GitHub, improving the overall resilience of our polyglot system.

A Note on Template Migration

Our move to JavaScript-powered templates and the adoption of a polyglot architecture with GraalVM involved a necessary transition from our previous Handlebars-based templating system. Migrating our old templates to the new framework presented an interesting challenge. To address this, we built automation tools to help us, which significantly streamlined the process and allowed us to efficiently transition to our new approach. While the specifics of this migration journey and the challenges we addressed are outside the scope of this post focused on GraalVM, for those interested in the details, we invite you to read our original blog post on the Picnic Engineering blog here.

The End of a Journey, The Start of a New Era

Moving from Handlebars to our custom TypeScript framework, and crucially integrating GraalVM, was not just a technical necessity but a transformative journey for the team. This migration reduced complexity, unified the template logic, and empowered us to leverage modern development practices like TypeScript’s strong typing and JSX’s expressive syntax. By combining automated tools, AI-powered improvements, and rigorous manual oversight, we ensured a seamless transition that preserved functionality while enhancing maintainability. Our innovative use of the Handlebars compiler, GraalVM integrations, and structured testing processes allowed us to bridge the old and new systems effectively.

This move not only modernized our codebase but also set a precedent for how we approach large-scale system overhauls — prioritizing automation, collaboration, and meticulous testing. It’s a testament to the team’s creativity and adaptability, showcasing how challenges can inspire inventive solutions. The adoption of GraalVM was a crucial component in achieving this, providing performant solutions, and ensuring reduced operational overhead, and seamless interoperability between Java and JavaScript. As we continue building with this new framework, now significantly enhanced by GraalVM, we’re confident in its scalability, performance, and ability to support the evolving needs of our developers and users.

While this post has focused on the role of GraalVM, there is more to be said about these efforts and the broader journey of our framework’s evolution. For the full story, we invite you to read our original blog post on the Picnic Engineering blog here.

JavaScript in Java: Driving Dynamic UIs with GraalVM at Scale was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

Can a Micronaut application start in milliseconds and run in a container smaller than most Go apps? It can, with GraalVM Native Image. Here’s how we transformed a traditional Java application into a fast to start, small to ship, and ready for the cloud native container.

The experiment started with a Micronaut web server, and ended with a 22MB fully static deployable image. How do we get there? With GraalVM Native Image, smart linking strategies, and a bit of magic at the end.

Along the way, we tested various build strategies, explored trade-offs, and measured real impact.

Yet, once compiled into a JAR and placed in a Docker container with a full JDK, this web server expanded to ~470MB. This result was observed with multiple OpenJDK distributions. That’s a non-starter if you’re trying to keep things lightweight for microservices or scale-to-zero platforms like Knative or AWS Lambda.

How small can we make it? The answer is, as it turns out, very small — if you’re willing to “go native” and even “static native”.

Step by Step: Slimming Down the Container

We started by benchmarking different ways to package and run the application — gradually replacing the JVM with custom runtimes, native executables, and, finally, fully static binaries. The results throughout this post were collected on an Oracle Linux 8 machine with 48 GB of memory and 4 CPUs to ensure consistency.

The demo is open source and reproducible: 👉 github.com/graalvm/workshops/tree/main/native-image/micronaut-webserver. Each step is automated via scripts and Dockerfiles, and the app serves real GraalVM documentation pages so you can benchmark accurately.

Here’s a brief overview of the most notable stages.

Step 1: The Starting Point — Running a JAR in a Container

Compiled as a JAR and run with java -jar, this web server worked perfectly—but the container size was still significant. Using a distroless java21-debian12 image instead of one built by installing an OpenJDK distribution into a slim OS container dropped the container size down to 216MB. Note that the static website pages contributed to the overall image size.

🧱 Image: gcr.io/distroless/java21-debian12
🚀 Startup: ~378ms
📦 Container size: 216MB

Not bad for a full Java web server, but could be further optimized for cold start and footprint.

Step 2: Creating a Custom JDK with jlink

Next, we tested jlink, a tool that creates a stripped-down Java runtime containing only the modules your application needs. Using jdeps to find dependencies and jlink to build the runtime, we saved quite some space:

🧱 Image: gcr.io/distroless/java-base-debian12
🚀 Startup: ~340ms
📦 Container size: 167MB

Here’s what the command flow looked like:

RUN ./mvnw clean package
RUN ./mvnw dependency:build-classpath -Dmdep.outputFile=cp.txt
RUN CP=$(cat cp.txt) && \
    MODULES=$(jdeps --ignore-missing-deps -q --recursive --multi-release 24 --print-module-deps --class-path "$CP" target/webserver-0.1.jar) && \
    echo "Modules: $MODULES" && \
    jlink \
      --module-path "${JAVA_HOME}/jmods" \
      --add-modules "$MODULES",jdk.zipfs \
      --verbose \
      --strip-debug \
      --compress zip-9 \
      --no-header-files \
      --no-man-pages \
      --strip-java-debug-attributes \
      --output jlink-jre

This gave us an instant 49MB win, just by trimming unused modules. Not a dramatic performance change, but a solid step toward efficiency.

Step 3: Compiling Ahead-of-Time — Going Native

Then came the game changer: GraalVM Native Image. We built the application ahead of time using Native Image Maven plugin, inside a multi-stage Docker build, and then packaged it in a distroless base image for the runner — no JVM required. The resulting image was dynamically linked.

🧱 Image: gcr.io/distroless/java-base-debian12
🚀 Startup: ~20ms
📦 Container size: 132MB

We just reduced startup time by almost 17x times, and the container size by 35MB! That’s how powerful native compilation can be. Still, we wanted more space savings.

Step 4: Optimizing a Native Image for File Size

What if we could shrink the native executable file itself? GraalVM offers the-Os flag, which optimizes for file size by skipping performance-costly optimizations. We added it to the build:

🧱 Image: gcr.io/distroless/java-base-debian12
🚀 Startup: ~20ms
📦 Container size: 102MB
📦 Binary size: 62MB (down from default 86MB!)

The binary size decreased by 24MB — with no change in behavior or startup time. Optimization for the win!

Additionally, we tested the new SkipFlow feature introduced in GraalVM for JDK 24. That’s a static analysis optimization that tracks unreachable branches to reduce code paths that may never run. It’s experimental, but was easy to enable: -H:+TrackPrimitiveValues -H:+UsePredicates.It shaved just 1MB off in our case, but that could grow with larger codebase.

Step 5: Running a Mostly Static Application — Going Static

So far we built dynamically linked native images. What if we link almost everything statically? With the --static-nolibc flag, we created a mostly static executable, linked against everything except glibc. This made it possible to switch to a smaller container image (base-debian12).

🧱 Image: gcr.io/distroless/base-debian12
🚀 Startup: ~20ms
📦 Container size: 89.7MB

That’s a further 12MB saved just by changing the base container.
Here is a breakdown of the native-maven-plugin configuration for this build:

<plugin>
  <groupId>org.graalvm.buildtools</groupId>
  <artifactId>native-maven-plugin</artifactId>
  <version>${native.maven.plugin.version}</version>
  <configuration>
    <imageName>webserver.mostly-static</imageName>
    <buildArgs>
      <buildArg>--static-nolibc</buildArg>
      <buildArg>-Os</buildArg>
    </buildArgs>
  </configuration>
 </plugin>

Step 6: Running a Fully Static Application — In an Empty Container

Now time for the real fun. With the--static --libc=musl flag, we could build a fully static native image—no OS-level dependencies, just a single binary. That meant we could use the scratch container—basically, just an empty filesystem. (scratch is an official Docker image.)

🧱 Image: scratch
🚀 Startup: ~20ms
📦 Container size: 69.2MB

A production-ready Micronaut web application was deployed in under 69MB, starting in milliseconds! That’s better than many compiled C++ apps.

Step 7. Going Extreme — UPX Compression

Could we go even smaller? We applied UPX, a binary compression tool, to our fully static executable and packaged it into the same scratch container. UPX decompresses the image at first, adding a CPU hit, but drastically reduces the image size.

🧱 Image: scratch
🚀 Startup: ~20ms
📦 Container size: 22.3MB
📦 Binary size: 20MB (down from 62MB!)

That’s nearly 20× smaller than the original container size. The app still started instantly and served requests flawlessly! The trade-off is that you lose visibility—you can’t easily inspect what was compressed out.

Before and After: The Numbers

Let’s compare where we started and where we landed:

Engineering Lessons Learned

Here’s what we took away from this process:

• Not all optimizations are equal. jlink is useful, but Native Image delivers orders-of-magnitude improvements in both size and startup time.
• Static linking unlocks ultra-tiny containers. If you don’t need a full OS, use scratch—you’ll get not only smaller images but also a reduced attack surface. Alternatives to scratch can be gcr.io/distroless/static or alpine:3 with a few more utilities and libraries inside.
• Base image size matters. Switching from java21-debian12 to base-debian12 or scratch made a huge difference. Don’t overlook this part.
• Compression can be the final trick. UPX is surprisingly effective, and worth experimenting with — though you’ll want to test CPU overhead in performance-sensitive apps.

On the final thought, if you’re building Java applications for the cloud and haven’t tried GraalVM Native Image, now is the time. The ecosystem is ready, the tooling is mature, and the results are hard to ignore.

Try It Yourself 💻

The demo sources, Dockerfiles, and step-by-step instructions are available on GitHub: github.com/graalvm/workshops/tree/main/native-image/micronaut-webserver.
If you prefer Spring to Micronaut, there is an identical Spring Boot version of this demo: github.com/graalvm/workshops/tree/main/native-image/spring-boot-webserver.
For more experiments and examples, look at Tiny Java Containers.
We welcome your feedback via Slack or GitHub.

— the GraalVM team

From JIT to Native: Path to Efficient Java Containers was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

Points-to analysis is a crucial part of every GraalVM Native Image build. In this blog post, we present SkipFlow, an extension to the points-to analysis that tracks primitive values and evaluates branching conditions during the analysis process. In our benchmarks, this reduced binary size by an average of 6.35% without increasing build time.

We start by providing a high-level overview of the static analysis in GraalVM Native Image. Then, we describe how SkipFlow improves the points-to analysis. Finally, we present an experimental evaluation and discuss future research in this area.

Points-to Analysis in GraalVM Native Image

A typical Java application has a lot of third-party libraries but uses only a fraction of their functionality. To avoid compiling methods that are not needed, Native Image performs a whole-program points-to analysis to determine all classes, methods, and fields that are so-called reachable, i.e., might be needed at runtime. Consider the example below to understand the motivation for using points-to analysis in this context.

void f(Iface i){
    if(i == null) throw new NullPointerException();
    if(i instanceof A){ ... }
    i.run();
}

By inspecting the method f only, we have little knowledge about the possible value of the parameter i. Therefore, we would have to assume that i.run() can call any implementation of the run() method of any subtype of Iface, which would lead to marking all such methods as reachable.

On the other hand, if we could compute that i will always be of a specific type B (not a subtype of A) and never null, we could replace the virtual invocation of i.run()with a direct invocation of the run() method available on the type B, therefore marking only a single method as reachable. Furthermore, we could remove both the null and type checks (including any code inside the corresponding branches). Points-to analysis tracks the possible types for all variables and fields in the program, making such optimizations possible. Employing points-to analysis leads to both smaller binaries and faster compile times.

Native Image runs the analysis using a data structure called a type flow graph. As the name suggests, this graph models the flow of types throughout the program. Nodes in the graph, which we call flows, represent method parameters, fields, variables, and various instructions relevant to the analysis. Directed use edges describe how the types can flow between nodes. Each flow maintains a typestate representing a set of types that can reach the given flow.

The type flow graph is expanded during the analysis. It starts from a set of root methods (e.g., main()) and gradually adds more nodes and edges as additional reachable code elements are discovered. The analysis enables pruning unreachable code, eliminating redundant type and null checks, and even devirtualizing method invocations for which only a single target method is computed. In the example above, we could reduce the content of the method f to a direct call to B.run().

However, precision is not the only metric we consider. Since the analysis is executed during every Native Image build, analysis time and memory footprint are equally important. We need an analysis that is both reasonably precise and fast. In some cases, we even sacrifice a bit of precision to improve scalability. For example, we use a technique called saturation, which works as follows: if the number of types observed for a given variable exceeds a given threshold (by default 20), the analysis stops tracking the flow of types precisely for that variable and removes it from the graph. This technique is motivated by compilers typically optimising only cases with few possible types. Saturation enables linear scaling with respect to the size of the program, yet with only a negligible effect on precision. To learn more about saturation, you can take a look at this publication: Scaling Type-Based Points-to Analysis with Saturation.

Introducing SkipFlow

The analysis Native Image currently runs (which we will denote as baseline in the rest of the blog) can be needlessly imprecise on specific code patterns. Consider the example below taken from the Dacapo Sunflow benchmark.

void render(..., Display display){
    if (display == null) {
        display = new FrameDisplay();
    }
    ...
}

The baseline analysis is able to determine that the parameter display will never be null. However, since it does not consider the control flow of the method, it still analyses the contents of the branch and considers the type FrameDisplay as instantiated. This might not seem to be a big problem, but the value of the variable display is eventually used as a receiver to call the imageBegin() method and FrameDisplay.imageBegin() transitively calls into AWT and Swing GUI libraries, none of which are actually needed. This means we analyse and subsequently compile a lot of dead code. Can we do better?

There are many techniques in the area of static analysis which could improve the precision of the baseline analysis, but they are typically too slow for our use case. Remember that the analysis runs in every build and has to process hundreds of thousands of methods in minutes or even faster.

The approach we took for increasing the precision of the analysis, called SkipFlow, is based on two key features. The first feature is evaluating branching conditions during the run of the analysis. To support this feature in the existing framework, we have introduced predicate edges into type flow graphs that encode a relationship between a branching condition and nodes within the branches. In the Dacapo Sunflow example above, a predicate edge would lead from the node representing the null check of display to the node representing the FrameDisplay instantiation. All flows with an incoming predicate edge are disabled by default. Such flows can accept values flowing into them via use edges, but they will not push any values further down the graph until enabled by their predicate. This makes it possible to delay evaluating the content of branches, such as the one above that instantiates a FrameDisplay object, until it is determined that the branch may be executed at runtime. In the particular case of Dacapo Sunflow, we were able to reduce the size of the image by more than 50%.

The second feature is tracking primitive values, which proves useful in cases where the condition is factored into a separate method, such as the example below.

void onExit(Thread thread){
     if (thread.isVirtual()){
         virtualThreads.remove(thread);
     }
}
 
 
public boolean isVirtual() {
    return this instanceof BaseVirtualThread;
}

The SharedThreadContainer.onExit() method, taken from the JDK, is a callback containing code that should be executed only for virtual threads. The check itself is offloaded into the Thread.isVirtual() method, which contains a simple type check. This is a common code pattern in the JDK. Tracking primitive values enables the propagation of boolean values (true and false) out of method calls, so that code specific to virtual threads can be removed unless the compiled application actually uses them.

Experimental Evaluation

We have evaluated SkipFlow using the Renaissance and Dacapo benchmark suites, and a set of microservices applications. Below, we present a chart showing the impact on binary size for a set of microservices applications. SkipFlow reduces the size of native images by 4.4% on average without negatively impacting the build time. In fact, image builds tend to be even slightly faster with SkipFlow enabled because there are fewer methods to analyse and compile.

Similar trends can be seen in Renaissance and Dacapo benchmark suites, which you can see in the charts below.

Across all three benchmark suites, binary size is reduced by 6.35%, on average. The evaluation was conducted using GraalVM for JDK 24 on a dual-socket Intel Xeon E5–2630 v3 processor running at 2.40 GHz, with 8 physical / 16 logical cores per socket and 128 GB of main memory, on Oracle Linux Server release 7.3.

Conclusion

SkipFlow is included in GraalVM for JDK 24, but is not yet enabled by default. To enable it, you can use the flags -H:+TrackPrimitiveValues -H:+UsePredicates. However, SkipFlow will be enabled by default in GraalVM for JDK 25 and is already available in Early Access builds! We encourage you to try it on your projects and share your feedback.

In future, we plan to improve SkipFlow analysis even further by using a more precise representation for primitive values, including the possible interval of values that a given variable can have.

If you are interested to learn more, you can take a look at this academic paper SkipFlow: Improving the Precision of Points-to Analysis using Primitive Values and Predicate Edges, which was presented at CGO’25.

SkipFlow: Producing Smaller Executables with GraalVM was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today, along with GraalVM for JDK 24, we are releasing version 24.2 of Graal Languages. This version is designed for use with GraalVM for JDK 24, but it is also compatible with the latest CPU releases of GraalVM for JDK 21, Oracle JDK 21, and OpenJDK 21. This release includes many exciting updates, including a Gradle plugin for GraalPy, scaling native Python across Java threads, a Continuation API in Espresso (Java on Truffle), the new Truffle Bytecode DSL, and more. Let’s take a look!

Alternatively, watch our release stream for the updates in this release and demos:

Graal Languages in Java ☕️

Starting from this release, users of GraalPy, GraalJS, and other Graal Languages must enable native access privileges to avoid warnings printed by the JVM. When using the module-path, pass the --enable-native-access=org.graalvm.truffle option to the java launcher, and when using the class-path, pass the --enable-native-access=ALL-UNNAMED option to resolve the new warning. Note that Truffle, the framework all Graal Languages are implemented in, automatically forwards the native access capability to all loaded languages and tools. Therefore, no further configuration is required. Denying native access with --illegal-native-access=deny will disable the optimizing runtime and the slower fallback runtime is used instead.

Context and Engine are now automatically closed when no longer strongly referenced. It is still recommended to close them explicitly whenever possible.

Moreover, the Value API has been extended: we added the ability to use Value#as(byte[].class) to copy the contents of a guest language byte buffer (Value#hasBufferElements()) to a new byte array. We also added support for the creation of strings from raw byte arrays and native memory using Value.fromByteBasedString(…) and Value.fromNativeString(…).

When embedding a Graal Language in a native image, language and instrument resources are now automatically included. By default, a separate resources folder is no longer created next to the image. See more in the Embedding Languages guide.

GraalPy 🐍

After adding a Maven plugin for GraalPy in the previous release, we now also ship a Gradle plugin that makes it easy to embed GraalPy in your Gradle projects! 🎉

You can simply add it to your Java projects as follows:

plugins {
    application
    id("org.graalvm.python") version "24.2.0"
}

graalPy {
    packages = setOf("pygal==3.0.5")
}

One of the great benefits of using GraalPy plugins is that they provide a way to easily configure the Python packages you want to use.

The new release of GraalPy also includes two new experimental features that can significantly boost the performance of Python in Java. GraalPy can now load native Python extensions multiple times in different contexts, which makes it possible to scale native Python across Java threads. For this, enable the python.IsolateNativeModules option and use the multi-context mode of GraalPy (we recommend starting with one GraalPy context per thread).

The second experimental feature is a new integration of Apache Arrow, a language-independent data representation, in GraalPy. With this, it is possible to directly share large amounts of data between Java and Python without having to copy between Java and Python object layouts. This can significantly reduce the time to process shared data, for example when using popular Python packages such as Pandas from Java:

See the native extensions documentation for more details. We will also add a guide on this to our demo repository soon.

Besides, we’ve also made several improvements to how foreign types are now treated in Python. Foreign objects are now given a Python class corresponding to their interop traits. This means, for example, that Java Map or List objects now appear as subclasses of Python's dict or list respectively, and they have all the expected methods on the Python side and behave as much as possible as if they were Python objects. We also added polyglot.register_interop_type and @polyglot.interop_type to add Python methods to given foreign classes when they are called from Python code. This makes it easier to adapt foreign interfaces to be more idiomatic in Python. Finally, when calling a method on a foreign object in Python code, Python methods are now prioritized over foreign members.

Check out the GraalPy changelog for all updates in this release.

To make it easier for you to get started with GraalPy, we’ve added several new demos and guides — check them out:

• Build a minimal Java application that embeds GraalPy
• Build a Java application that embeds openai Python package with GraalPy
• Embed qrcode Python package with GraalPy in JBang
• Embed SVG charting library pygal with GraalPy in Micronaut
• Embed SVG charting library pygal with GraalPy in Spring Boot.

See more on GitHub:

graal-languages-demos/graalpy at main · graalvm/graal-languages-demos

GraalJS and GraalWasm 🌍

We implemented several ECMAScript proposals, such as Error.isError, Math.sumPrecise, Atomics.pause, Promise.try, Uint8Array to/from base64 and hex, RegExp.escape, Iterator Sequencing, Source Phase Imports, and Regular Expression Pattern Modifiers.

GraalJS now also supports WebAssembly/ES module integration, so Wasm modules can be loaded via import statements. This, for example, makes it even easier to embed Rust, Go, or C++ code compiled to Wasm in a Java application. Here’s an example of this being used in a generated JavaScript binding for a Rust library that now just works on GraalJS:

import * as wasm from "./photon_bg.wasm";
export * from "./photon_bg.js";
import { __wbg_set_wasm } from "./photon_bg.js";
__wbg_set_wasm(wasm);
wasm.__wbindgen_start();

We also updated the version of our Node.js runtime to 22.13.1.

For more details, take a look at the changelogs for GraalJS and GraalWasm.

Espresso ☕️

In Espresso, our Java runtime built on Truffle, we added an exciting new experimental feature: theContinuation API. This API lets you pause a running program, save its state, and then resume it later. The heap objects can be serialized to resume execution in a different JVM instance running the same code (for example, after a restart).

There are several use cases where continuations could be particularly interesting:

• Speculative Execution: speed up computations where CPU-intensive work is blocked by long waiting periods;
• Implementing Coroutines/Yield;
• Web Request Handling: Maintaining state across HTTP requests without global variables or session storage.
• Undo/Redo Functionality: Capturing application state at various points to enable undoing or redoing actions.
• Distributed Computing: Serializing continuation state, allowing distributed systems to migrate units of work;
• Live Programming/Hot Code Swapping.

To get started with the Continuation API, add org.graalvm.espresso:continuations:24.2.0 to your pom.xml/build.gradle with provided scope. See also our serialization example.

You can find more Espresso updates in the changelog.

TruffleRuby 💎

In this release, we updated TruffleRuby to Ruby 3.3.5 and switched to the Panama NFI backend for improved C extension performance. With this new backend, C extensions such as sqlite3, trilogy , and json, are now around 2x to 3x faster thanks to the more efficient Panama upcalls in JVM mode.

See more updates, in particular compatibility improvements and bug fixes, in the changelog.

Truffle Language Implementation Framework

We added the Bytecode DSL, a new framework to simplify implementing bytecode interpreters on top of Truffle. The goal is to generate the tricky and tedious details of a bytecode interpreter from an AST-like specification. The generated interpreter supports a variety of features, including tiered interpretation, bytecode quickening, boxing elimination, instrumentation, continuations, and serialization. Additionally, the generated code implements several optimizations for interpreter speed and memory footprint. The next step for us is to put the new DSL to use in GraalPy and other Graal Languages. If you’d like to use it, please see our extensive user guides and tutorials to get started.

Community and Ecosystem

• With GraalPy you can easily create interactive SVG charts with Pygal in your Java applications — see how for Micronaut and Spring Boot.
• GraalPy and GraalWasm featured are featured as Innovators in InfoQ‘s Java 2024 Trends Report! 🚀
• See our Jfokus talk for the best practices and tips for extending your Java applications with GraalPy.
• Christian Humer, Truffle project lead, talked to Adam Bien on his airhacks.fm podcast about GraalVM, Truffle, Futamura projections, and more.

Conclusion

We’d like to take this opportunity to thank our amazing contributors and community for all the feedback, suggestions, and contributions that went into this release.

If you have feedback for this release or suggestions for features you would like to see in future releases, please share them with us on Slack, GitHub, or BlueSky.

— the GraalVM team

What’s new in Graal Languages 24.2 was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today we are releasing GraalVM for JDK 24!

As always, we release GraalVM on the same day that Java 24 is released, so you can use GraalVM as your Java 24 JDK.

You can already download GraalVM and check the release notes for more details. Keep reading this blog post to see what’s new in this release!

Alternatively, watch our release stream for the updates in this release and demos:

More Peak Performance with Machine Learning 🙌

You might know about ML-based profile inference in Native Image: in the absence of user-supplied profiling information, Native Image in Oracle GraalVM uses a pre-trained ML model to predict the execution probabilities of the control flow graph branches. This enables powerful optimizations, improving the peak performance of native images out of the box. In this release, we are introducing a new generation of ML-enabled profile inference — GraalNN. With GraalNN, we are observing a ~7.9% peak performance improvement on average on a wide range of microservices benchmarks (Micronaut, Spring, Quarkus, and others).

To enable this optimization, pass the -O3(optimize for peak performance) flag to Oracle GraalVM Native Image. Note that this approach doesn’t require a training run and a follow-up build — you can get improved peak throughput with just one build.
For more implementation details, you can see our paper “GraalNN: Context-Sensitive Static Profiling with Graph Neural Networks”, which we will present at this year’s International Symposium on Code Generation and Optimization (CGO). We are working on further improving this optimization, so expect even higher performance in GraalVM for JDK 25!

Even Smaller Native Executables 📦

Points-to analysis is a crucial part of the GraalVM Native Image build process. While Java projects might contain tens of thousands of classes coming from dependencies, we can avoid compiling all the methods by analyzing which classes, methods, and fields that are reachable, i.e., actually needed at runtime.

In this release we are introducing SkipFlow — an extension of our points-to analysis that tracks primitive values and evaluates branching conditions during the run of the analysis. It allows us to produce ~6.35% smaller binaries without increasing the build time. In fact, image builds tend to be even slightly faster with SkipFlow enabled because there are fewer methods to analyze and compile.

You can find more details about this optimization in our CGO paper, “SkipFlow: Improving the Precision of Points-to Analysis using Primitive Values and Predicate Edges”, and a follow-up blog post that we will share soon.

This optimization is included in GraalVM 24 as experimental and not yet enabled by default. To test it out, you can use the flags -H:+TrackPrimitiveValues and -H:+UsePredicates. Feel free to share your feedback with us, as we plan to enable it by default in GraalVM for JDK 25.

Premain Support for Java Agents 🥷

One of the common requests from both our users and partners was to extend the Java agents support in Native Image. Up to now, agents have been supported by Native Image but with some constraints:

• The agent had to run and transform all classes at build time;
• The premain of the agent was only executed at build time;
• All of the classes needed to be present in the agent jar;
• The agent should not have manipulated the classes used by Native Image.

With this release, we are taking the first step towards agent support at runtime. We have added support for premain for static agents, and it currently it works as follows:

• At compile time, use -H:PremainClasses= to set the premain classes;
• At run time, use -XX-premain:[class]:[options] to set premain runtime options are set along with main class’s arguments.

This now allows premain methods to be initialized when the native image actually runs.

We would like to thank Alibaba for their contributions to this feature.

We have more work planned in GraalVM for JDK 25. In the meantime, you can help us by telling us which agents specifically you would like to use with Native Image — let us know in the GitHub ticket or via our community platforms.

Vector API support in Native Image 🚀

The Vector API enables vector computations that reliably compile to optimal vector instructions, resulting in performance superior to equivalent scalar computations.

In this release, we have continued our work to optimize more Vector API operations on GraalVM, with more operations now efficiently compiled to SIMD code, where supported by the target hardware:

• operations on Vector API masks,
• masked Vector API loads and stores,
• general Vector API rearrange operations,
• and Vector API loads/stores to and from memory segments.

Additionally, we’re excited to announce that Vector API support in Native Image is now on par with JIT!🎉 To enable Vector API optimizations when building native images, pass the --add-modules jdk.incubator.vector and -H:+VectorAPISupport options at build time.

One of the areas where the Vector API really shines is large language models, as most of the compute heavy operations there are matrix and vector multiplications. As an example, you can take a look at Llama3.java, a hobby project of our colleague, Alfonso² Peterssen. It’s a one-file local LLM inference engine implemented in pure Java, utilizing the latest features of Java’s Vector and FFM APIs and powerful optimizations coming from GraalVM. By combining all of these, you get a blazing fast local LLM assistant, compiled with GraalVM Native Image, running purely on CPU:

You can see how fast the engine is — with the optimizations coming from GraalVM, the model “responds” blazing fast — in this demo, the 1B parameter Llama 3.2 model with 4.5 bits/weight quantization runs at 52.25 tokens/s. Better yet, by utilizing more aggressive AOT optimizations, such as model preloading at build time, you can completely eliminate startup overhead.

Please note that Vector API support on GraalVM is considered experimental. We would be happy to receive feedback as we further improve the number of optimized Vector API operations.

More efficient applications with Native Image 🌿

Native Image is well-known for giving applications fast startup, low memory and CPU usage, and compact packaging. Lately there is another aspect of Native Image where we see increasing interest from the community —resource savings. Thanks to AOT compilation and optimizations, Native Image application can run more efficiently, reducing resource consumption — including electricity usage 🔋. As an example, we measured energy consumption of Spring PetClinic running on JIT and on Native Image in several scenarios with increasing load:

• Scenario A: 1 curl request, 1s after curl response
• Scenario B: 1 curl request, 10s total run time
• Scenario C: 4000 requests/s, 20 seconds
• Scenario D: 4000 requests/s, 100 seconds

As we see, the natively compiled version of the application consistently consumes less energy, even under constant load. Our initial findings are also aligned with a community study performed by Ionut Balosin.

If you are looking for a way to reduce resources usage of your applications, consider compiling them with GraalVM.

New security features in Native Image🛡️

As you might know, Oracle GraalVM Native image offers SBOM support, which is essential for vulnerability scanning. To generate an SBOM file in CycloneDX format, pass the --enable-sbom flag to embed it into a native executable, or --enable-sbom=classpath,export if you want to add it to the resources path or export as JSON.

With this flag you can generate an SBOM this way for any project, but for even more accurate SBOMs, we recommend using the Maven plugin for GraalVM Native Image. The plugin creates a “baseline” SBOM by using cyclonedx-maven-plugin. The baseline SBOM defines which package names belong to a component, helping Native Image associate classes with their respective components—a task that can be tricky when using shading or fat JARs. In this collaborative approach, Native Image is also able to prune components and dependencies more aggressively to produce a minimal SBOM.

These enhancements are available starting with plugin version 0.10.4 and are enabled by default when using the --enable-sbom option.

In this release we also added support for dependency trees: the SBOM now provides information about component relationships through the CycloneDX dependencies field format. This dependency information is derived from Native Image’s static analysis call graph. Analyzing the dependency graph can help you understand why specific components are included in your application. For example, discovering an unexpected component in the SBOM allows for tracing its inclusion through the dependency graph to identify which parts of the application are using it.

Additionally, we added support for class-level metadata for SBOM components. You can enable it with --enable-sbom=class-level. This metadata includes Java modules, classes, interfaces, records, annotations, enums, constructors, fields, and methods that are part of the native executable. This information can be useful for advanced vulnerability scanning to determine if a native executable with the affected SBOM component is actually vulnerable, thereby reducing the false positive rate of vulnerability scanning, and for better understanding which components are included in the native executable. Note that including class-level metadata increases the SBOM size substantially — include it only when you need detailed information about your native executable’s contents.

We have also added SBOM support to GraalVM’s GitHub action. You can now automatically generate a highly accurate SBOM with Native Image and submit it to GitHub’s dependency submission API. This enables simple integration with all the powerful security tooling that GitHub provides:

• Vulnerability tracking with GitHub’s Dependabot;
• Dependency tracking with GitHub’s Dependency Graph. The Dependency Graph shows the union of the submitted SBOM components and what GitHub infers automatically.

You can activate this feature in setup-graalvm with the option native-image-enable-sbom.

Build reports

To better understand your Native Image builds and the contents of produced executables, you can use Build reports. Those are HTML reports that can be generated alongside your Native Image build, providing details about the following:

• Build overview such as the build environment, analysis results and resources usage, which can also be exported for integration purposes;
• Code area and image heap which can help you understand which methods and objects make up your application;
• Resources tab showing included, missing, and injected (such as by frameworks) resources;
• SBOM information that also can be exported as JSON (in Oracle GraalVM);
• Profiling information visualization represented as a flame graph and histogram (requires supplying profiles).

To get started with build reports, pass --emit build-report when building an application. To learn more about Build Reports, navigate to the docs.

Debugging updates

In this release we introduced several debugging updates:

• We have added a GDB Python script (gdb-debughelpers.py) to improve the Native Image debugging experience — learn more.

• We added support for emitting Windows x64 unwind info. This enables stack walking in native tooling, such as debuggers and profilers.
• We updated debug info from DWARF4 to DWARF5 and now store type information in DWARF type units. This helped us reduce the size of debugging information by 30% 💪

Monitoring updates 📈

We have added experimental support for jcmd on Linux and macOS. jcmd is used to send diagnostic command requests, where these requests are useful for controlling Java Flight Recordings, troubleshooting, and diagnosing applications. To try it out, add --enable-monitoring=jcmd to your application build arguments. See the documentation for more details.

We would like to thank Red Hat for their contributions to this feature.

Usability 👩‍💻

• We have removed the"customTargetConstructorClass" field from the serialization JSON metadata. All possible constructors are now registered by default when registering a type for serialization. RuntimeSerialization.registerWithTargetConstructorClass is now deprecated.
• Serialization JSON reachability metadata can now be included in reflection metadata via the "serializable" flag.

Here is how such an entry would look for a regular serialized.Type:

{
  "reflection": [
    {
      "type": "serialized.Type",
      "serializable": true
    }
  ]
}

and for a proxy class:

{
  "reflection": [
    {
      "type": {
        "proxy": ["FullyQualifiedInterface1", "...", "FullyQualifiedInterfaceN"],
        "serializable": true
      }
    }
  ]
}

Miscellaneous

• Native Image now targets armv8.1-a by default on AArch64. Use -march=compatibility for best compatibility or -march=native for best performance within machines with the same CPU features.
• We added support for Java module system-based service loading — for example you can now specify module Foo { provides MyService with org.example.MyServiceImpl; } in module-info.java.

Community and Ecosystem

• According to InfoQ’s Java 2024 Trends Report, GraalVM, and specifically Native Image, is now considered a technology being used by the Early Majority. We are happy to see that the ongoing work of our team and community to make Native Image stable, fast, and production-ready, is being recognized. Along with Native Image, we are glad to see GraalPy and GraalWasm featured in Innovators! 🚀
• Great news for maintainers of projects hosted on GitHub: you can now easily use GraalVM with setup-java!🎉
• While we are on the topic of GitHub, you can now build with GraalVM using GitHub’s Linux ARM64 hosted runners, and we already added support for it in setup-graalvm — get started.
• We are happy to welcome Sandra Ahlgrimm and Microsoft to the GraalVM Advisory Board!
• Micronaut 4.7 added experimental support for LangChain4j and integration with GraalPy, so you can invoke Python code from Java easily in a Micronaut application.
• AWS CRT (Common Runtime) package for Java added support for Native Image. Cold start request processing time using the GraalVM Native Image experienced a 4X reduction for 90% of the requests. Warm start requests took 18–25% less time to process using the GraalVM Native Image.

• With Spring Boot 3.4, SBOM is now auto-detected when building a native image with --enable-sbom=sbom.
• Quarkus introduced support for Model Context Protocol, which enables AI models to interact with applications and services in a decoupled way, and works great with GraalVM Native Image— see how.

Conclusion

We’d like to take this opportunity to thank our amazing contributors and community for all the feedback, suggestions, and contributions that went into this release.

If you have feedback for this release or suggestions for features that you would like to see in future releases, please share them with us on Slack, GitHub, or BlueSky.

Now go ahead and try the new GraalVM! 🚀

— the GraalVM team

Welcome, GraalVM for JDK 24!🚀 was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

The year is coming to an end and many exciting things happened in the GraalVM project and in our community! In this blog post, we want to share with you some of the highlights.

Graal JIT in Oracle JDK 23 🚀

Starting with Oracle JDK 23, the Oracle GraalVM JIT compiler is now included among the compilers available as part of the Oracle JDK.

This means that Oracle JDK users can easily get access to the advanced performance optimizations, offered by GraalVM!🎉 There are several studies showcasing the performance benefits of using Oracle GraalVM JIT — you can check out the Renaissance benchmark suite, or performance study by Ionut Balosin and Florin Blanaru.

Now it’s your time to take Graal JIT for a spin!

Faster than ever on JIT and AOT 🏁

Graal JIT is known to be very fast. We love seeing users randomly discovering this and observing performance gains with zero tuning. It is that easy!

You might know that we have this big vision of AOT at the speed of JIT, and with every release we are working to that end. We are constantly tracking multiple performance metrics, to make sure that with Native Image you get the best possible peak performance in addition to fast startup and low memory usage. One of our benchmark applications is Spring PetClinic. For GraalVM for JDK 23 we benchmarked it on Ampere A1 machines, and here are the results:

More optimizations coming up in GraalVM for JDK 24!😎

Parsing 1 Billion Rows in Java in 0.3 Seconds 🤯

Speaking of speed, we can’t leave out the 1BRC 1️⃣🐝🏎️ challenge, which concluded at the beginning of the year. There are many great blog posts dissecting the competition and each of performance optimizations used by the contestants. Most of them suggest that before any manual tuning, you should start by choosing an advanced compiler, that will give you performance gains out of the box, and Graal JIT shined throughout the competition, both in JIT and AOT modes. If you are looking for a fun and highly educational video to watch during your Christmas break, may I suggest that you go with a 1BRC deep dive from Thomas Wuerthinger and Roy van Rijn at Devoxx Belgium:

Native Image developer experience 👩‍💻

The developer experience of working with Native Image is one of our priorities, and it has evolved significantly in the recent years. We are always working to reduce the time and resources needed for builds, and with every release you can see improvements. It also doesn’t hurt if you have a very good machine, as observed by Marcus Hellberg :)

We know that now that more and more users are using GraalVM in production, a smooth experience using libraries is crucial. To that end, Native Build Tools (NBT), our Maven and Gradle plugins, now enable access to the GraalVM Reachability Metadata repository by default. This means that for projects that use NBT (and frameworks that rely on NBT), configuration for known libraries will be resolved automatically. We also actively work with framework and library teams to expand what can be easily built with Native Image, and smooth out the experience. Currently, our community-maintained list of frameworks and libraries integrating with Native Image contains over 200 projects!🤯

We are also working on several projects that will improve Native Image configuration and usability.

There were several great new Native Image features introduced in 2024, such as new compacting garbage collector, new optimization level for size, and others — you can learn more about them in our release blog posts (GraalVM for JDK 23, GraalVM for JDK 22).

Expect even more DX improvements in 2025!

Graal Languages

GraalPy and GraalWasm are now stable and ready for production workloads!🎉 They have joined Java and JavaScript as our supported Graal languages.

This year we’ve spent a lot of effort on improving compatibility and developer experience of GraalPy. You might remember that embedding Graal languages in Java is just a matter of adding two Maven dependencies — org.graalvm.polyglot:polyglot and, for example, org.graalvm.polyglot:python. You can also use our graalpy-maven-plugin (or graalPy Gradle) to conveniently configure the embedding as a part of your normal Java build configuration.

Additionally, you can now use GraalPy within the setup-python GitHub Action!

Another major update in the languages space is that after two years of R&D we’ve finally merged the Bytecode DSL. Bytecode interpreters have the same peak performance as ASTs, but they can be encoded with less memory, and can benefit further from additional performance optimizations.

As the easiest way to get started with Graal languages, try our demos:

GitHub - graalvm/graal-languages-demos: Graal Languages - Demos and Guides

Community and User Stories

We work closely with our community to build productive partnerships, get valuable feedback, and further improve GraalVM for everyone. One of our favorite platforms for collaboration is our yearly GraalVM Community Summit. It’s a two-day event in Zurich where we meet with our partners and community members, discuss recent updates and our roadmap, and have working sessions on various topics. Every year the event grows bigger and bigger, and we are already at max capacity of our office :) This year we had a truly impressive lineup of participants, with representatives from Alibaba, Amazon, Apple, BellSoft, Broadcom, Enso, Google, JetBrains, Microsoft, MicroDoc, Neo4J, Red Hat, SAP, Shopify, TornadoVM, and others, as well as all GraalVM teams.

This year was very productive for open-source community and governance. We did a public call for lead maintainers for GraalVM backport repositories, and they are now led by Foivos Zakkak, who has track record of contributing to the GraalVM project and maintaining related distributions.

Also, Sandra Ahlgrimm from Microsoft joined the GraalVM Advisory Board to help us drive the project forward and contribute to its vision.

Here are a few more notable updates from our community and users:

• More than 2000 repositories on GitHub are now using the GraalVM GitHub action!🚀
• GraalVM meets IntelliJ IDEA! ❤️ We have a great collaboration with the IntelliJ IDEA team, and they implemented several great features for our users. GraalJS now acts as a modern execution engine for the HTTP client, you can have syntax highlighting for polyglot applications, and most recently they are working on streamlining debugging experience for GraalVM native images.
• The“State of Spring” survey results are out, and they offer interesting insights. 11% of Spring Boot users already run GraalVM natively compiled applications in production, 26% of users are currently evaluating, and 31% are planning to develop native applications with GraalVM!
• One of my favorite projects this year is llama3.java, built by our brilliant colleague Alfonso² Peterssen. It’s a complete LLM inference engine in Java! No C, no Python, no dependencies, and no calls to cloud-based LLMs — a complete inference engine, which along with a model gives you a full-blown local LLM assistant. Under the hood it’s using the power of the FFM & Vector APIs, and GraalVM for starting the application with zero overhead. How cool is that!👾
• Google Java Code Formatter is now available as very fast platform specific native binary executables, built with GraalVM.
• Apple have announced their new configuration language, Pkl, which is built on top of Truffle.
• You can speed up Timefold Solver startup by 20x with Native Image!
• AWS added support for Native Image to AWS CRT Client for Java, reducing cold start request processing time by 4x reduction for 90% of the requests.
• Micrometer enables passing observability data to multiple platforms & backends, and works like a charm with Native Image:

• You can now use GraalVM as your JDK in the setup-java GitHub action!
• It’s never been easier to run integration tests for Kafka applications with Testcontainers using the new GraalVM-based native Kafka Docker image! 😍

Conclusions

We are already actively working on the next release of GraalVM due in March. We also have several ongoing major projects in the GraalVM space, such as Native Image Layers, GraalOS, and further compatibility and performance improvements for all our projects.

Thank you for being a part of our community and for all your contributions, suggestions, and support. We wish you happy holidays and plenty of time to recharge, and see you in 2025!🎄

GraalVM in 2024: A year in review was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

Machine learning (ML) enables the training of models that, based on the characteristics of a program, can accurately predict its execution. In this blog we will explain how we used ML to develop the static profiler GraalSP (a static profiler that predicts profiles in Native Image), integrated it into Oracle GraalVM Native Image, and achieved a 7.5% improvement in runtime performance!

In the first part of this blog, we describe static profilers and compare them to their dynamic counterparts, which we covered in a previous blog. In that blog we discussed program profiles and how they “guide” optimizations. Using a sorting example we will delve into the design and development of GraalSP. At the end we’ll also present the results of integrating ML into Native Image and discuss the deployment of the ML models into production.

Dynamic and Static Profilers

In AOT compilation, dynamic profilers work by building an instrumented image, collecting profiles, and then building an optimized image. They collect high-quality profiles but also have a few drawbacks. First, they complicate the optimization process by requiring two builds and a profile-collection run. This process is usually time and memory consuming, placing an extra burden on programmers and the machines used for optimization. Also, finding appropriate workloads for profile collection can be challenging.

Fortunately, there is a much cheaper alternative where there’s no need to go through the run-build-run compilation cycle or hunt for suitable inputs for profile collection. It’s called “static profiling” or “static profile prediction”. A static profiler is a profiler that doesn’t collect a profile during program execution — instead, it predicts a program’s profile. A state-of-the-art static profiler takes advantage of a machine learning model to predict a profile based on a set of static features that characterize a program.

Figure 1 illustrates the pipeline of a Profile-Guided Optimization (PGO) build driven by a static profiler relying on an ML model. A static profiler extracts features (we will get back to them later!) that characterize a program and then perform ML model inference to predict a profile. This predicted profile is then used just like one obtained by dynamic profiling: the compiler utilizes the information about program “execution” to create an optimized executable. This way, an ML model enables the compiler to utilize a profile without needing to run the program, reducing the usability burden and the challenge of finding suitable workloads for profile collection.

Introducing the Graal IR

It is important to note that a static profiler does not operate on a program’s source code but use the compiler’s intermediate representation (IR) instead. A compiler translates a program’s source code into IR, a form that is more manageable and suitable for various optimizations, such as eliminating redundant code and duplicating frequent loops.

In this context, Native Image uses Graal Intermediate Representation (Graal IR) to represent a program as a graph. Graal IR is a high-level IR that captures a program’s structure and includes additional information that enables the compiler to perform advanced analyses and optimizations, leading to better-optimized programs.

Graal IR represents a program as a graph consisting of nodes that correspond to the control flow and nodes that correspond to the data flow in the program. For example, consider the simple for loop. Graal IR translates the for loop into the IR graph shown below (Figure 2), with control flow edges colored red and data flow edges colored blue. The condition i < n is parsed into an IF node that evaluates the value of the counter i. The loop body corresponds to the true branch of the IF control split node in the IR. Therefore, executing the loop body corresponds to executing the true branch of the corresponding IF node.

You can learn more about Graal IR in one of our previous blog posts and in the paper Graal IR: An Extensible Declarative Intermediate Representation.

GraalSP: The Static Profiler for Native Image

Now that we are familiar with the pipeline of static profilers and Graal IR, let’s discuss the ML in Native Image. We developed GraalSP: a precise, highly efficient, lightweight, polyglot, and robust static profiler as a part of the Native Image tool. Let’s delve into GraalSP using an example — we’ll use the heap sort function to demonstrate how (static) profiling can help us improve performance.

Running Example: Heap Sort

In the code block below we show the source code of the heapSort function from the Java Development Kit (JDK). This sorting implementation uses the pushDown method to push elements down the heap.

/**
* Sorts the specified range of the array using heap sort.
*
* @param a the array to be sorted
* @param low the index of the first element, inclusive, to be sorted
* @param high the index of the last element, exclusive, to be sorted
*/
private static void heapSort(int[] a, int low, int high) {
   for (int k = (low + high) >>> 1; k > low; ) {
       pushDown(a, --k, a[k], low, high);
   }
   while (--high > low) {
       int max = a[low];
       pushDown(a, low, a[high], low, high);
       a[high] = max;
   }
}

Impact of the Program Profiles on Performance

Function inlining optimization determines whether to inline function calls based on the probability of executing loop bodies in for and while loops. More precisely, function inlining is a very complex optimization, and decisions about inlining a pushDown invocation aren’t made solely based on the probabilities of loop body execution. However, these probabilities play a significant role in determining whether or not to inline calls. Therefore, optimization of the heapSort function highly depends on program profiles that contain information about the execution probabilities of the for and while loops.

Consider sorting an array of 10 million integer values using the heapSort function from the JDK. Function inlining optimization can inline calls to the pushDown method, reducing the overhead of function calls during the sorting process. When the pushDown method calls are inlined, the average sorting time is 1.80 seconds. Conversely, if these calls are not inlined, the average sorting time increases to 2.18 seconds. As inlining calls to the pushDown method can speed up program execution by more than 20%, the execution probabilities of the loop bodies are very important.

Goal: Accurately Predict Program Profiles

Our goal is to predict the execution probabilities of the bodies of the for and while loop. Let’s focus on, for example, for loop. Predicting the probability of executing the loop body translates to predicting the probability of executing the true branch of the corresponding IF node in the Graal IR; so our goal is to predict the execution probability of the true branch of the IF node corresponding to the for loop. To do so, first, we need to take a look at the Graal IR and “define” branches of the IF node.

ML Features that Characterize Code

In Figure 3, we illustrate the IF node in the Graal IR that corresponds to the for loop (named “1. If”), along with its true and false branches defined by the blocks of a control flow graph (CFG).

If you’re wondering about the CFG, it’s essentially composed of blocks, where each block contains nodes from the IR graph. The CFG consolidates both control flow and data flow from the Graal IR, providing a clear representation of the program’s execution order and enhancing comprehension of its flow. Therefore, we utilized the CFG to characterize the branches of IF statements.

We “define” branches of the IF node in terms of the nodes in the Graal IR and blocks of the CFG built on top of the Graal IR. The true branch of the “1. If” node consists of blocks B2-B8, while the false branch consists of blocks B9-B24. Once we define blocks corresponding to the branches of the IF node, to fully characterize the IF node we also extract features from the CFG block that hosts the IF node (block B1 in our example) as well as blocks that point to that block in the CFG (block B0).

The features we extract include, for example, the estimated assembly size of a branch, the estimated number of CPU cycles the computer will perform to execute instructions from the branch, and the nesting loop depth of an IF node. The margin of this blog is too narrow to discuss all the features. For those interested in more details, our paper GraalSP: Polyglot, efficient, and robust machine learning-based static profiler provides more details. Here, it is important to note that the feature characterizing the IF node, for which we aim to predict the probability of executing its true branch, is represented by a vector of floating point numbers.

Machine Learning for Profile Prediction

After extracting the feature vector, we use supervised learning techniques to train the ML model to predict profiles. We use the XGBoost ensemble of decision tree (DT) models for regression to predict profiles.

A DT model uses a tree-like structure consisting of nodes, branches, and leaves to model the data. Each node evaluates a feature and directs decisions down the tree, while leaf nodes predict profiles. On the left side of Figure 4, we illustrate a shallow DT model that predicts the branch execution probability of a true branch based on the loop depth of an IF node, as well as the assembly size and number of CPU cycles of a branch. For example, if an IF node is at a depth of two or more and the estimated CPU cycles for a true branch are less than five, the DT model predicts the execution probability of that branch to be 0.15. The main benefits of DTs are their interpretability, speed, and ease of use.

To improve prediction performance, reduce overfitting, and increase accuracy, we utilize the XGBoost ensemble, combining DTs as weak learners. On the right side of Figure 4, we illustrate an ensemble consisting of 1,500 decision trees. Each tree in the ensemble predicts the execution probability for a target branch, and the ensemble aggregates all predictions (for example, by averaging them) to determine the outcome.

Usage of the ensembles enables us to achieve precise predictions, while usage of the decision trees enables us to achieve a highly efficient static profiler. Also, by using lightweight decision trees, we end up with a small model of only ~250 kilobytes.

By defining the static profiler on top of the IR of the Graal compiler, we’ve created a polyglot static profiler capable of predicting profiles for all programs compiled to Java bytecode (for example, Java, Scala, and so on!).

Furthermore, we designed and developed two profile prediction heuristics that handle scenarios where input data deviates from the real-world Java and Scala programs. Of course, these heuristics can’t predict profiles better than ML models, but they can help prevent the model from making mistakes. For instance, one of the heuristics ensures that the probability of executing the body of a loop is not less than 0.2. This way, the ML model won’t make cardinal mistakes on frequent loops. By slightly increasing the binary size of the generated programs, these heuristics have enabled us to create a robust static profiler that effectively handles outliers.

The impact of a static profiler on program performance can vary depending on the program’s code. To evaluate the impact, we use programs from test suites Renaissance, DaCapo, and DaCapo con Scala. We integrated GraalSP into Native Image and achieved a 7.46% speedup in execution time (geometric mean) compared to the default configuration. The default image build assumes a uniform distribution of execution probabilities over the branches of a control split. Figure 5 reports the geomean speedup of programs aggregated according to the test suite.

Runtime improvement comes at the cost of an average increase in the size of generated programs of only 3.9%. The increased size of generated binary files results from duplication-based compiler optimizations. The static profiler generates profiles for the entire codebase, even though usually only a small section of the code is executed. Duplication-based optimizations duplicate code even in sections that won’t be executed, thus slightly increasing the size of the compiled programs.

It is important to emphasize that the performance of programs optimized using PGO with dynamically collected profiles is much higher than those optimized using profiles predicted by GraalSP. In our experiments, PGO with dynamically collected profiles produces programs that are 33% faster and 15% smaller. As expected, the quality of the dynamically collected profiles is superior because they lack the inherent errors found in ML models. Additionally, dynamically collected profiles include information that GraalSP currently does not predict: method call profiles, reached types in virtual calls, details about monitor locking and unlocking, and so on. Of course, as there is no such thing as a free lunch, these performance improvements comes with the hurdles of dynamic profiling.

Model Inference: Deployment to Production

Since the releases of GraalVM for JDK 17 and GraalVM for JDK 20 (version 23.0), GraalSP has been enabled by default in Oracle GraalVM! During the default build, you’ll find out that Native Image optimizes your program using PGO with ML-inferred profiles. Figure 6 illustrates the integration of GraalSP and dynamic profiling in Native Image. When users enable dynamic profiling, Native Image instruments the code and runs the instrumented executable to collect profiles. Otherwise, if users do not enable the dynamic profiler, Native Image will run the GraalSP to predict profiles and optimize programs based on the predicted values.

GraalSP uses the ONNX Java Runtime, developed by Microsoft for cross-platform accelerated ML. This ensures compatibility with various architectures, including Windows amd64, Linux amd64 and aarch64, and Darwin amd64 and aarch64, providing flexibility and usability of GraalSP across different platforms. Also, by using the ONNX runtime, we implemented static profiling with a compilation time overhead of only 10%.

Conclusion

To summarize, GraalSP is enabled by default in Oracle GraalVM Native Image and offers the benefits of PGO without requiring profile collection. GraalSP characterizes programs in terms of Graal IR and uses the XGBoost ensemble to predict profiles. Native Image then uses these predicted profiles to perform PGO and create optimized programs. This represents the first successful application of ML in Oracle GraalVM. However, at Oracle Labs, we are preparing some exciting updates, improvements, and ML novelties to be announced very soon. Stay tuned!

For more details about the ML magic inside Oracle GraalVM, please refer to our paper GraalSP: Polyglot, efficient, and robust machine learning-based static profiler.

Machine Learning-Driven Static Profiling for Native Image was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s been two years since we published a revision to our Native Image Quick Reference and much has changed since then! The biggest update? Native Image became part of the GraalVM distribution, no need for a separate download! In the meantime, our team has focused on improving the developer experience by shortening build times, adding new useful features, and including several widely-used host options that have now become public APIs. In this quick reference, we highlight some of the key updates to Native Image, particularly around optimizations and performance.

This quick reference is designed to fit neatly on an A4 or US Letter paper, making it easy to print. The PDF versions are available below:

• A4 Paper — Download PDF
• US Letter Paper — Download PDF

Building

There are two ways to build Java applications ahead of time: using native-image on the command line or with Native Build Tools.

Building with native-image on the command line remains straightforward, the same way as you would use java:

• to compile a class: native-image [options] <mainclass> [args…]
• to compile a JAR file: native-image [options] -jar <jarfile> [args…]
• to compile the main class in a module: native-image [options] -m <module>[/<mainclass>] [args…]

Building a shared library has not changed and requires passing the --shared option to the native-image tool.

For container deployments, we recommend taking advantage of Native Image containerization and linking options (Linux only) to reduce dependencies on the runtime libraries. You can create a fully static native image using the --static --libc=musl option and run it in a lightweight container, even a scratch container, without any runtime dependencies!

Another option is to build a mostly statically linked binary by passing the --static-nolibc option. A mostly static native image links all the shared libraries on which it relies (zlib, JDK-shared static libraries) except the standard C library, libc. This type of native image is useful for deployment in a Distroless base container which provides glibc.

Native Build Tools

The recommended method for building native images is through Native Build Tools plugins for Maven and Gradle.

In a Maven project, you define the plugin as part of a Maven profile in pom.xml as follows:

<profile>
    <id>native</id>
    <build>
      <plugins>
        <plugin>
          <groupId>org.graalvm.buildtools</groupId>
          <artifactId>native-maven-plugin</artifactId>
          <version>${buildtools.version}</version>
          <executions>
            <execution>
              <id>build-native</id>
              <goals>
                <goal>compile-no-fork</goal>
              </goals>
              <phase>package</phase>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </build>
  </profile>
</profiles>

To build, simply use:

./mvnw -Pnative package

Skip tests with -DskipTests if needed: ./mvnw -DskipTests -Pnative package.

In a Gradle project, you define the plugin in build.gradle (the configuration for Kotlin is provided in the plugin documentation).

plugins {
  id 'org.graalvm.buildtools.native' version '${buildtools.version}'
}

Build a native executable and run the application at one step:

./gradlew nativeRun

Both plugins support running JUnit Platform tests as native code:

• Maven: ./mvnw -Pnative test
• Gradle: ./gradlew nativeTest

Native Image Maven and Gradle plugins basic configuration can be significantly extended. For example, in a Maven project, pass options to native-image directly through the plugin configuration:

<configuration>
    <buildArgs>
       <buildArg>--option</buildArg>
    </buildArgs>
</configuration>

In a Gradle project, use:

graalvmNative {
    binaries {
        main {
            buildArgs.add("--option")
        }
     }
}

You can find more information in the plugins documentation.

Optimizing

Native Image provides multiple ways to optimize the resulting native executable for performance, size, build time, debuggability, and other metrics.

Improved performance

To improve the performance, throughput in particular, we strongly recommend using Profile-Guided Optimization (PGO). PGO enables the Graal compiler to leverage profiling information and sets the optimization level to -O3, similar to when it is running as a JIT compiler, when AOT-compiling your application. For this, perform the following steps:

1. Build the application with --pgo-instrument.
2. Run the instrumented application with representative workloads to create profiling data, saved as default.iprof.
3. Rebuild using the --pgo option (or --pgo=<custom>.iprof for specific profiles), generating an optimized native version of your application.

Find more information on this topic in Basic Usage of Profile-Guided Optimization. (Available with Oracle GraalVM.)

The next recommendation is to improve latency and throughput by switching from the default Serial garbage collector to the G1 garbage collector. You can enable G1 by adding the --gc=G1 option to native-image (only available with Oracle GraalVM on Linux). Here are a few options that you can specify when doing performance tuning:

• -H:G1HeapRegionSize: Define the G1 region size.
• -XX:MaxRAMPercentage: Set the maximum heap size as a percentage of physical memory.
• -XX:MaxGCPauseMillis: Set target maximum pause times.

You can find a full list in the documentation.

For example, to create a native image using G1 GC with a region size of 2MB and a maximum pause time goal of 100ms, run:

native-image --gc=G1 -H:G1HeapRegionSize=2m -R:MaxGCPauseMillis=100 HelloWorld

To execute the native image from above and override the maximum pause time goal, run:

./helloworld -XX:MaxGCPauseMillis=50

For optimal performance without PGO, you can use the new option -O3 Although it may increase the build time.

Another option is optimizing for a specific machine type. You can enable more CPU features if you deploy your application on the same machine or machine with similar specs using the-march=native option. This instructs the compiler to use all instructions that it finds available on the machine the binary is generated on.

If the generated image is distributed to users with many different, and potentially very old machines, use -march=compatibility. This reduces the set of instructions used by the compiler to a minimum and thus improves the compatibility of the generated binary.

For faster build time

To reduce build times, enable the quick build mode with -Ob. This mode performs fewer compiler optimizations, reducing the overall compilation phase time, and is suitable for development builds. However, production builds should benefit from full optimizations. More CPU cores also significantly improves the build time: more CPUs — faster builds.

On another note, Native Image prints a valuable build output to the console with the information on the resource usage statistics such as garbage collection, peak RSS, and CPU load.

For smaller binary size

Use -Os to prioritize smaller executable sizes, ideal for cloud or container deployment environments where the occupied space matters. This option retains essential optimizations from -O2 at the cost of reduced performance.

For reduced memory footprint

When executing a native image, Java heap settings are determined based on the system configuration and GC. To override this default mechanism, set a maximum heap size for more predictable memory usage at run time. For example:

./myapp -Xms2m -Xmx10m -Xmn1m

You may want to gather garbage collection logs if your expectations are not met:

./myapp -XX:+PrintGC -XX:+VerboseGC

Find more information about Memory Management in Native Image on the website.

Useful Developer Tools

If the file size of your native binary increased unexpectedly, you can now generate a Build Report using --emit build-report to analyze embedded resources and other data. Build Reports enable you to explore the contents of the generated images in greater detail and in a more appealing manner than on the command line. See an example here. (Available with Oracle GraalVM.)

To identify your application dependencies, you can generate a Software Bill of Materials (SBOM) using the new --enable-sbom option which supports CycloneDX by default. This embeds a GZIP-compressed SBOM file that you can later extract into a human-readable format or submit to a vulnerability scanner. (Available with Oracle GraalVM.)

Native Image supports more application monitoring features than before, such as Java Management Extensions (JMX), Native Memory Tracking (NMT), and so on. Enable monitoring features at build time with the --enable-monitoring option, which defaults to all. To enable only selected features, choose from: heapdump, jfr, jvmstat, jmxserver, jmxclient, nmt, and threaddump. Enabling any of these features will increase the size of the executable.

For performance analysis, Native Image now supports Linux Perf profiler. You can gather the runtime statistics with perf as follows:

perf stat ./myapp

For additional details on profiling, refer to Linux Perf Profiler Support in Native Image.

Summary

The updated quick reference is designed to keep developers up-to-date on the latest Native Image features. It covers essential building, optimization, and developer tools options. Whether you’re building for containers, aiming for optimized performance, or debugging complex issues, this quick reference is a good place to start.

Download and print it to keep it at hand, and happy coding with GraalVM Native Image!

—
The GraalVM team

Native Image Quick Reference — GraalVM for JDK 23 was originally published in graalvm on Medium, where people are continuing the conversation by highlighting and responding to this story.