oracle/graal · critical · IllegalArgumentException

unsupported barrier sequence %s

Error message

unsupported barrier sequence %s

What it means

On aarch64, GraalHotSpotVMConfig's initializer validates BarrierSetAssembler_nmethod_patching_type against the known NMethodPatchingType constants (stw_instruction_and_data_patch, conc_instruction_and_data_patch, and Oracle-build-only conc_data_patch). An unrecognized value throws IllegalArgumentException('unsupported barrier sequence N') because Graal cannot emit correct nmethod patching for unknown barrier-set sequences.

Source

Thrown at compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/hotspot/GraalHotSpotVMConfig.java:627

    public final long shenandoahWriteBarrierPre = getAddress("ShenandoahRuntime::write_barrier_pre", -1L, hasShenandoahGC);

    // aarch64 specific nmethod entry barrier support
    // @formatter:off
    public final int BarrierSetAssembler_nmethod_patching_type = getFieldValue("CompilerToVM::Data::BarrierSetAssembler_nmethod_patching_type", Integer.class, "int", -1, osArch.equals("aarch64"));
    public final long BarrierSetAssembler_patching_epoch_addr = getFieldValue("CompilerToVM::Data::BarrierSetAssembler_patching_epoch_addr", Long.class, "address", -1L,
                    osArch.equals("aarch64"));
    public final int NMethodPatchingType_stw_instruction_and_data_patch = getConstant("NMethodPatchingType::stw_instruction_and_data_patch", Integer.class, -1, osArch.equals("aarch64"));
    public final int NMethodPatchingType_conc_instruction_and_data_patch = getConstant("NMethodPatchingType::conc_instruction_and_data_patch", Integer.class, -1, osArch.equals("aarch64"));
    // conc_data_patch is currently only exposed by Oracle JDK builds.
    public final int NMethodPatchingType_conc_data_patch = getConstant("NMethodPatchingType::conc_data_patch", Integer.class, -1, osArch.equals("aarch64") && isOracleVmVendor);
    // @formatter:on

    {
        if (osArch.equals("aarch64")) {
            if (BarrierSetAssembler_nmethod_patching_type != NMethodPatchingType_stw_instruction_and_data_patch &&
                            BarrierSetAssembler_nmethod_patching_type != NMethodPatchingType_conc_instruction_and_data_patch &&
                            (!isOracleVmVendor || BarrierSetAssembler_nmethod_patching_type != NMethodPatchingType_conc_data_patch)) {
                throw new IllegalArgumentException("unsupported barrier sequence " + BarrierSetAssembler_nmethod_patching_type);
            }
        }
    }

    // Tracking of the number of monitors held by the current thread. This is used by loom but in
    // JDK 20 was enabled by default to ensure it was correctly implemented.
    public final int threadHeldMonitorCountOffset = getFieldOffset("JavaThread::_held_monitor_count", Integer.class, "intx");
    public final int threadLockStackOffset = getFieldOffset("JavaThread::_lock_stack", Integer.class, "LockStack");
    public final int lockStackTopOffset = getFieldOffset("LockStack::_top", Integer.class, "uint32_t");
    public final int lockStackEndOffset = getConstant("LockStack::_end_offset", Integer.class);
    public final int threadOmCacheOffset = getFieldOffset("JavaThread::_om_cache", Integer.class, "OMCache");
    public final int threadUnlockedInflatedMonitorOffset = getFieldOffset("JavaThread::_unlocked_inflated_monitor", Integer.class, "ObjectMonitor*");
    public final int omCacheOopToOopDifference = getConstant("OMCache::oop_to_oop_difference", Integer.class);
    public final int omCacheOopToMonitorDifference = getConstant("OMCache::oop_to_monitor_difference", Integer.class);

    public final long throwAndPostJvmtiExceptionAddress = getAddress("JVMCIRuntime::throw_and_post_jvmti_exception");
    public final long throwKlassExternalNameExceptionAddress = getAddress("JVMCIRuntime::throw_klass_external_name_exception");
    public final long throwClassCastExceptionAddress = getAddress("JVMCIRuntime::throw_class_cast_exception");

View on GitHub (pinned to a66e9ccd1d)

Solutions

1. Use a Graal/JVMCI (or JDK with embedded libgraal) version at least as new as the HotSpot sources it runs on, so the patching-type constants match
2. If you build HotSpot yourself, set the barrier set's _nmethod_patching_type to one of the supported constants
3. As a stopgap, disable JVMCI/Graal on that VM until versions are aligned

When it happens

Trigger: Running Graal on an aarch64 HotSpot build whose BarrierSetAssembler::_nmethod_patching_type has a value Graal does not enumerate — e.g. a newer/patched/experimental collector barrier set, or a non-Oracle build exposing a type only expected on Oracle JDKs; the check runs in the config instance initializer at first Graal use.

Common situations: New or backported HotSpot aarch64 builds adding a patching type before Graal catches up; custom VM builds; running a Graal version older than the JDK it is embedded in on aarch64.

Related errors

• VM config values missing that should be present in %s:%n
• VM config values not expected to be present in %s:%n %s
• Graph was permanetly frozen.
• unknown verbosity:
• NodeBitMap was modified between the calls to hasNext() and n

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