oracle/graal · critical · JVMCIError
VM config values missing that should be present in %s:%n
Error message
VM config values missing that should be present in %s:%n %s
What it means
GraalHotSpotVMConfigAccess verifies that VM config entries the compiler requires (fields/offsets/constants read via getFieldOffset/getConstant with expectPresent) actually exist in the JVMCI-provided HotSpotVMConfig store. Missing entries accumulate in 'missing' and reportErrors() throws JVMCIError listing the runtime, java.home, and each missing value — the classic 'Graal does not match this HotSpot build' error.
Source
Thrown at compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/hotspot/GraalHotSpotVMConfigAccess.java:182
return;
}
boolean warn = "warn".equals(value);
Formatter message = new Formatter().format(rawErrorMessage);
String javaHome = getSavedProperty("java.home");
String vmName = getSavedProperty("java.vm.name");
if (warn) {
message.format("%nSet the %s system property to \"ignore\" to suppress ", JVMCI_CONFIG_CHECK_PROP_NAME);
message.format("this warning and continue execution.%n");
} else {
message.format("%nSet the %s system property to \"ignore\" to suppress ", JVMCI_CONFIG_CHECK_PROP_NAME);
message.format("this error or to \"warn\" to emit a warning and continue execution.%n");
}
message.format("Currently used Java home directory is %s.%n", javaHome);
message.format("Currently used VM configuration is: %s%n", vmName);
if (warn) {
System.err.println(message);
} else {
throw new JVMCIError(message.toString());
}
}
/**
* @see HotSpotVMConfigAccess#getAddress(String, Long)
*/
public long getAddress(String name, Long notPresent, boolean expectPresent) {
if (isPresent(name, vmAddresses, expectPresent)) {
return access.getAddress(name, notPresent);
}
return notPresent;
}
/**
* @see HotSpotVMConfigAccess#getAddress(String)
*/
public long getAddress(String name) {
if (isPresent(name, vmAddresses, true)) {View on GitHub (pinned to a66e9ccd1d)
Solutions
- Use the Graal/compiler artifacts that ship with (or are built for) the exact JDK you run — align JDK and Graal versions
- Rebuild Graal from source against the target JDK's HotSpot sources (mx --jdk ... build) so required constants resolve
- If the mismatch is known-benign during bring-up, start with -Ddebug.jdk.graal.jvmciConfigCheck=warn to log and continue, then fix the real mismatch
Example fix
# before java -XX:+UseJVMCICompiler -graal-old.jar ... # JVMCIError: VM config values missing ... # after: use the matching build java -XX:+UseJVMCICompiler # stock JDK with its own embedded Graal # or during bring-up only: java -Ddebug.jdk.graal.jvmciConfigCheck=warn -XX:+UseJVMCICompiler ...
Defensive patterns
Strategy: fallback
Validate before calling
// sanity check before enabling JVMCI on an unusual JDK: run with // java -Ddebug.jdk.graal.jvmciConfigCheck=warn -XX:+UseJVMCICompiler -version // and inspect warnings to detect missing config values without aborting
Prevention
- Never mix a compiler jar across JDK major versions
- Pin JDK + Graal versions together in CI matrices
- Use jvmciConfigCheck=warn only during bring-up, not production
When it happens
Trigger: Initializing GraalHotSpotVMConfig against a HotSpot build whose vmstructs/JVMCI metadata lacks entries the compiler expects — e.g. a Graal jar from one JDK release running on another JDK version, or a JVMCI interface version mismatch; entries are added whenever isPresent(..., expectPresent=true) fails.
Common situations: Dropping a graal/compiler jar built for JDK N onto JDK N+1 (renamed/removed HotSpot fields); custom or older JVM builds with incomplete JVMCI exports; mixing libgraal-enabled and jargraal artifacts across JDK versions.
Related errors
- VM config values not expected to be present in %s:%n %s
- unsupported barrier sequence %s
- No backend available for specified GPU architecture \"%s\"
- %s has params
- %s is not an enum type
AI-assisted analysis of oracle/graal@a66e9ccd1d (2026-08-14).
Data as JSON: /api/errors/6c213008e43e88cf.
Report an issue: GitHub.