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

  1. Use the Graal/compiler artifacts that ship with (or are built for) the exact JDK you run — align JDK and Graal versions
  2. Rebuild Graal from source against the target JDK's HotSpot sources (mx --jdk ... build) so required constants resolve
  3. 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

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


AI-assisted analysis of oracle/graal@a66e9ccd1d (2026-08-14). Data as JSON: /api/errors/6c213008e43e88cf. Report an issue: GitHub.