CrucibleVM alpha

Three builds, one of them shipped

One script does it all; the steps it takes are below, for doing them by hand. Every option is a -H: option behind -H:+UnlockExperimentalVMOptions.

# from the release archive; in a source tree, crucible/pgo.sh
tar xzf cruciblevm-0.4.0-linux-x86_64.tar.gz
cruciblevm/crucible/pgo.sh --name app --run '$APP <your workload arguments>' -- -cp app.jar com.example.Main

1. Build an image that records

   source crucible/env.sh && cd substratevm
   mx native-image -O3 -cp app.jar -o app-recording \
       -H:+UnlockExperimentalVMOptions -H:+CrucibleInstrument com.example.Main

2. Run it on a representative workload

   It writes crucible-profile.json when it exits. The recording image runs about twice as slow as normal.

   ./app-recording <the usual arguments>

3. Build the image you ship

   mx native-image -O3 -cp app.jar -o app \
       -H:+UnlockExperimentalVMOptions -H:CrucibleProfile=crucible-profile.json com.example.Main

What it does

The profile work reaches the compiler through extension points upstream already has, with a few lines changed upstream where one was missing, so rebasing onto a new GraalVM stays simple. The collector and System.arraycopy changes are changes to upstream's own files.

• The class library's profile

  A build without a profile gives the library's branches the probabilities other programs recorded for them, from a profile that comes with the builder.

• Branch probabilities

  Counted in every place a method is inlined, and applied before inlining, so layout, inlining and the loop optimizations all see them.

• Receiver types

  Counted at every virtual call in every calling context. The inliner tests for the common receivers first and inlines their methods.

• Loop range splitting

  A hot loop whose checks always go one way runs its middle part without them — which also lets the vectorizer take it.

• Cold code for size

  Methods the run never reached don't inline and are compiled as -Os would: images 7 to 12% smaller at the same speed.

• Code layout

  The code section is ordered by how often each method ran.

• Hot methods at -O3

  Below -O3, hot methods still get its inliner, unrolling and vectorization — -O3 speed in an -O2-sized image on the samples.

• The collector, too

  GC branches are profiled like the program's, and the serial collector promotes and copies the way a profiled program wants.

• Young collection on several threads

  New and opt-in: built with -H:+ParallelYoungCollection, the serial collector scans its young generation on up to nine threads. Programs that collect on several threads of their own gain most.

• Smaller objects

  The recording lists the types the run locked; the others it used drop their eight-byte monitor slot. They still lock correctly, only slowly, so record a workload that locks what production locks.

• Faster System.arraycopy

  Copies go to memmove with one card mark per copy, instead of a scalar loop with a barrier per element.

How it compares

Profile-guided binary from each compiler, Oracle GraalVM 25.0.4 against CrucibleVM on GraalVM Community Edition 25.4.4.1.1, same machine, -O3, every binary checked for identical output; without a profile, each builder at its default level with nothing asked for. Every workload is listed, including the ones where CrucibleVM loses. What it was measured on is below; one machine is one machine, so please run your own.

Renaissance, fourteen benchmarks, from sampled stacks

0.871 of Oracle's time

With smaller objects; 0.881 without them in the same session

The same, from a counted profile

0.913 of Oracle's time

The plain recording, no second sampled run, before smaller objects

Behind Oracle

1 of fourteen

rx-scrabble, by 1%, on 0.4.0 as released (2026-10-30). Over three sessions before smaller objects, scala-stm-bench7 was behind too, by up to 2%

With the young collection on several threads

0.824 of Oracle's time

On by default since 0.4.0, measured on 0.4.0 as released, on 8 processors; 0.858 with the serial collector in an earlier session

Without a profile, at the default level

0.917 of Oracle's time

A plain build, nothing asked for, against Oracle's; ahead on thirteen, level on rx-scrabble; images 17% larger

Below 1 means less time than Oracle's binary: 0.871 is 13% less. It is the geometric mean, over the benchmarks, of CrucibleVM's time divided by Oracle's.

Services and samples

The services are built and recorded with crucible/pgo.sh under the load they are timed with. The samples are built from counted recordings, medians of eleven runs.

Quarkus and Spring Boot Quarkus's own benchmark, with each builder's profile

The applications, settings and chart of Quarkus's spring-quarkus-perf-comparison, out of the box, with four native images of each application: Oracle GraalVM without a profile and with --pgo, CrucibleVM without a profile and with crucible/pgo.sh. Both profiles are recorded under the load the images are timed with, one minute of /fruits at 100 connections. The two JVM bars, on Temurin 25, are there as in Quarkus's chart.

With a profile, Spring Boot serves 31% more requests a second built by CrucibleVM than by Oracle GraalVM, 5,838 against 4,458, and 32% more without one, 4,028 against 3,046. Quarkus is level without a profile, 9,440 against 9,427, and 3% behind with one, 14,550 against 15,018. Boot and first response are level: 24 ms for both on Quarkus with a profile, 110 ms on Spring Boot. Memory after the first request is level on Quarkus with a profile, 45 MB, 4% higher on Spring Boot, 119 MB against 114, and 11 to 12% higher on both without a profile. The chart does not show memory under load: there CrucibleVM's Spring Boot image peaks at 372 MB against Oracle's 194, both under -Xmx512m, and its Quarkus image at 87 MB against 151.

Measured on the machine below the way Quarkus's lab measures, from its main.yml: its time-to-first-request script; resident memory from pmap 20 s after the start and after the first request; requests a second over 30 s at 100 connections after 2 minutes of warm-up and a 30 s pause; a fresh database for every measurement, Quarkus's PostgreSQL 17 image and settings; three rounds, the runtimes in turn, averaged as Quarkus's charts are. Different from Quarkus's lab: oha in place of Hyperfoil; the application on two cores (four threads), the database on two and the load generator on two, where the lab gives each its own cores of a 64-thread Xeon; the first round's boot time left out, since the image was not yet in the file cache and a native image took 4 to 10 times longer. Quarkus 3.39.4, Spring Boot 4.1.1, -Xmx512m -Xms512m for every runtime and -XX:+UseNUMA on the JVM, CrucibleVM at f3dc403398e, serial collector. These numbers are not comparable with Quarkus's published ones. The chart is drawn by Quarkus's generator from quarkusio/benchmarks, with the eight native runtimes added.

Renaissance from sampled stacks, three sessions of five rounds

These sessions were before smaller objects. With them: akka-uct 5.4% faster, scala-stm-bench7 4.8%, scala-kmeans, scala-doku, mnemonics, scrabble, reactors and rx-scrabble 1.4 to 2.2%, four within 1%, and philosophers 3% slower.

The README gives each benchmark's result as a percentage or a range over the three sessions, and groups some benchmarks that fell in the same range; this table keeps its grouping. Memory is three rounds, with each collector choosing its heap: CrucibleVM peaks lower on seven of the fourteen, about the same on five, higher on two.

What it was measured on

Only Linux on x86-64 has been built and measured. Two builds of the same source can differ by 2 to 5% on some of these benchmarks, philosophers most of all, so a difference of that size on one of them is not a result.

One machine. The earlier GraalVM 25.3 results, every number behind these, and everything that was tried and did not work are in the README, the roadmap and docs/issues/.

Download it, or build it from source

CrucibleVM 0.4.0 for Linux x86-64 is a tar.gz that needs neither mx nor the source tree: unpack it and use cruciblevm/bin/native-image and cruciblevm/crucible/pgo.sh. It was built on Rocky Linux 10; 0.1.0 was checked on Ubuntu 24.04 with only gcc libc6-dev zlib1g-dev python3 installed, 0.2.0 added the parallel young collector and two run-time options for the serial collector's memory, 0.3.0 collects the old generation once it holds twice what the last complete collection kept, which brings Spring PetClinic under load from 311 MB to 240 to 280, and 0.4.0 collects the young generation on several threads by default. To build it yourself you need mx and a labs JDK 25; crucible/env.sh sets both up, and the first build takes 20 to 60 minutes.

git clone https://github.com/SiteNetSoft/crucible.git && cd crucible
source crucible/env.sh
cd substratevm && mx build
mx crucible-e2e      # records, rebuilds and checks that the profile was applied

Get involved

CrucibleVM has been measured on a handful of benchmarks. What it needs most is more programs: try it on yours, with crucible/pgo.sh, and say what happened. A wrong answer, a crash, a slower binary and a faster one are all worth reporting.

• Report wrong output

  The program behaves differently built with a profile than without. This is the report that matters most; the guide says how to narrow it down, and a small program that shows it is worth more than any description.

  Open a report

• Share a result

  Faster or slower than without a profile, or than Oracle GraalVM's binary. Slower is as welcome as faster: the results above include where CrucibleVM loses, and yours should too.

  Report a result · Show and tell

• Ask a question

  How to record a service, why a build applied little of its profile, or whether something is a problem at all.

  Discussions

• Send a change

  Code, a benchmark or documentation. A change to what the compiler does comes with what it was measured to do, slower included. Commits are signed off under the Developer Certificate of Origin, git commit -s; there is no agreement to sign.

  Contribution guide

Found a security vulnerability? Do not open a public issue; report it privately, as SECURITY.md says.