oracle/graal · error · IOException

Unknown replay register config kind ${kind}

Error message

Unknown replay register config kind ${kind}

What it means

BinaryReplayCodec throws this IOException while decoding a replay register config from a binary replay file. The file encodes an architecture kind byte and the decoder only knows AMD64, RISCV64, and AARCH64. Any other kind value means the replay was produced by an unsupported or newer GraalVM version, or the file is corrupt/truncated so the kind field reads garbage.

Source

Thrown at compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/hotspot/replaycomp/BinaryReplayCodec.java:1212

    }

    @SuppressWarnings("unchecked")
    private static RegisterConfig readRegisterConfig(ObjectCopierInputStream in, ReadState state) throws IOException {
        int kind = in.readPackedUnsignedInt();
        TargetDescription targetDescription = (TargetDescription) readValue(in, state);
        List<Register> allocatable = (List<Register>) readValue(in, state);
        return switch (kind) {
            case AMD64_ARCHITECTURE ->
                new AMD64HotSpotRegisterConfig(targetDescription, allocatable, readBooleanFlag(in));
            case RISCV64_ARCHITECTURE -> {
                readBooleanFlag(in);
                yield new RISCV64HotSpotRegisterConfig(targetDescription, allocatable);
            }
            case AARCH64_ARCHITECTURE -> {
                readBooleanFlag(in);
                yield new AArch64HotSpotRegisterConfig(targetDescription, allocatable);
            }
            default -> throw new IOException("Unknown replay register config kind " + kind);
        };
    }

}

View on GitHub (pinned to a66e9ccd1d)

Solutions

  1. Re-record the replay file on the same GraalVM version and same architecture you replay on
  2. Verify the replay file was not modified in transit (checksum it) and re-generate it
  3. If you maintain a fork/new architecture, add a case to the switch in BinaryReplayCodec.java:1212 and a matching write path
  4. Confirm the target architecture of the replaying JVM matches the recording one (e.g. not replaying an x86_64 recording on arm64)

Example fix

// before: replay recorded on JVM A into file recorded on JVM B
// after: re-record and replay with the identical build
// java -XX:+UnlockExperimentalVMOptions -XX:DumpReplay=true ... on the same JVM/image version
Defensive patterns

Strategy: validation

Validate before calling

// Before decoding, confirm producer/consumer agree on architecture set
String recordedArch = System.getProperty("graal.replay.arch"); // or parse header
if (!Set.of("AMD64", "riscv64", "aarch64").contains(recordedArch)) {
    throw new IllegalArgumentException("Replay arch not supported by this codec: " + recordedArch);
}

Try / catch

try {
    codec.readRegisterConfig(in);
} catch (IOException e) {
    if (e.getMessage().startsWith("Unknown replay register config kind")) {
        // reject the file early, request a re-record on a supported architecture
    } else { throw e; }
}

Prevention

When it happens

Trigger: Calling the binary replay decoding path (ReplayDecoder / BinaryReplayCodec.readValue on a register config record) with a replay file that was recorded on a machine whose Architecture.nameId does not map to AMD64_ARCHITECTURE, RISCV64_ARCHITECTURE, or AARCH64_ARCHITECTURE, or with a file whose bytes are misaligned from an incompatible codec version.

Common situations: Replaying a file recorded with a different/newer GraalVM build that added a new architecture kind; mixing replay files between JVM versions; hand-editing or truncating a .rep file; recording on an exotic architecture not yet in the switch.

Related errors

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