oracle/graal · critical · JVMCIError
VM config values not expected to be present in %s:%n %s
Error message
VM config values not expected to be present in %s:%n %s
What it means
The mirror of the missing-values check: entries the compiler declared as NOT expected (expectPresent=false reads, or values present only on other platforms/architectures) but which DO appear in the VM config store are collected in 'unexpected' and reported by reportErrors() as JVMCIError 'VM config values not expected to be present'. It catches metadata drift in the other direction — HotSpot exposing things this Graal build assumes are absent.
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
- Align the Graal/JVMCI build with the running JDK's HotSpot sources so present/absent expectations match
- Rebuild or upgrade the compiler so the entry's expectPresent flag reflects the current VM
- Use -Ddebug.jdk.graal.jvmciConfigCheck=warn only as a temporary bring-up measure to confirm nothing else breaks
Defensive patterns
Strategy: fallback
Prevention
- Build Graal against the exact HotSpot sources it will run on
- Treat 'unexpected present' reports as version skew, same as missing values
- Keep arch-conditional constant expectations in sync when porting
When it happens
Trigger: Reading a config entry with an architecture/platform-conditional expectation (e.g. an aarch64-only or Oracle-build-only constant) on a JVM where that entry is nevertheless present — typically a VM build that now exports a field for all platforms while the Graal build assumed it was conditional.
Common situations: Cross-version mixes where a constant became unconditional in a newer HotSpot; custom VM builds enabling optional metadata globally; Graal artifacts built from different HotSpot sources than the running VM.
Related errors
- VM config values missing that should be present in %s:%n
- 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/4ce89c80c39aeb06.
Report an issue: GitHub.