Stream: git-wasmtime

Topic: wasmtime / issue #11572 Fine grain control over fuel cons...

Wasmtime GitHub notifications bot (Aug 29 2025 at 21:00):

fuzing opened issue #11572:

We're hoping to migrate from wasmer to wasmtime but we need fine grained control over fuel consumption based on a per wasm operator usage pattern.

In wasmer we can set a tunable cost function and then use a metering middleware function that might look something like......

fn cost_function(operator: &Operator) -> u64 {
    match operator {
        Operator::LocalGet { .. } | Operator::I32Const { .. } => 2,
        Operator::I32Add { .. } => 4,
        _ => 1,
    }
}

Is something like this possible in wasmtime.

Thank you for this great project.

Wasmtime GitHub notifications bot (Aug 29 2025 at 21:01):

fuzing edited issue #11572:

We're hoping to migrate from wasmer to wasmtime but we need fine grained control over fuel consumption based on a per wasm operator usage pattern.

In wasmer we can set a tunable cost function and then use a metering middleware function.

The cost function itself might look something like......

fn cost_function(operator: &Operator) -> u64 {
    match operator {
        Operator::LocalGet { .. } | Operator::I32Const { .. } => 2,
        Operator::I32Add { .. } => 4,
        _ => 1,
    }
}

Is something like this possible in wasmtime.

Thank you for this great project.

Wasmtime GitHub notifications bot (Aug 29 2025 at 21:18):

cfallin commented on issue #11572:

Something like this is theoretically possible, sure; the main questions would be around the API design and how we ensure that it remains reasonably stable and doesn't expose too much.

I can imagine passing a Box<dyn Fn(&Operator) -> u64> on a Config used to compile code. That would have some performance impact on translation because of the dynamic dispatch, and would also expose that we use wasmparser under the hood, but maybe that's fine -- I see no issue; others chime in if they disagree.

There are also questions around how much context is reasonable to give to this cost function -- I'm not sure what purpose your customization serves, but e.g. if you want to make integer adds very expensive for some reason, this is fine, whereas making calls to specific imports (or whatever) expensive may require more context about module contents.

Then there are questions about the precise guarantees we provide: if we allow users to specify precise fuel amounts, is the expectation that the count will be exactly precise at every step? That does, e.g., constrain how we do batching of the updates somewhat.

In the end, if that API is acceptable, it would come down to: would you be willing to contribute a PR?

Wasmtime GitHub notifications bot (Aug 29 2025 at 21:42):

fitzgen commented on issue #11572:

We would probably only expose this functionality when the reexport-wasmparser feature is enabled, because Operator in particular changes semi frequently as WIP Wasm specs evolve.

https://github.com/bytecodealliance/wasmtime/blob/0744262f79e235b172331f5ba1a2c43b5aedcbfb/crates/wasmtime/Cargo.toml#L357-L371

Wasmtime GitHub notifications bot (Aug 29 2025 at 21:48):

cfallin commented on issue #11572:

Ah, yes, and also we would not want to re-export a single type without re-exporting the whole wasmparser crate so other types (used within Operator arms) could be named by the embedder as needed.

(I forgot we had that feature -- I was even the one who added it, d'oh!)

Wasmtime GitHub notifications bot (Aug 29 2025 at 21:50):

fuzing commented on issue #11572:

Thanks for the quick feedback. Your guess at our use-case is pretty accurate - we "price" expensive instructions at a higher rate than less expensive ones.

No issues with the idea of a non-semver'ed re-export of wasmparser and that this feature would need to be opted into to make functionality like this work.

I'll take a look at what it will take to generate a PR and then take a crack at it.

Cheers, and thank you again for your lightning response.

Wasmtime GitHub notifications bot (Feb 04 2026 at 15:40):

d-sonuga commented on issue #11572:

Has this already been done or, @fuzing, are you still going to work on this.

If not, I'd like to take a crack at it - need the exact use-case.

cc @fitzgen, @cfallin

Wasmtime GitHub notifications bot (Feb 07 2026 at 02:23):

AlbertMarashi commented on issue #11572:

You can use the Non-Exhaustive Attribute to handle potential future changes and additions the enum list to ensure that library implementers handle future variants in a future-compatible way.

Wasmtime GitHub notifications bot (Feb 07 2026 at 02:26):

AlbertMarashi edited a comment on issue #11572:

You can use the Non-Exhaustive Attribute to handle potential future changes and additions the enum list to ensure that library implementers handle future variants in a future-compatible way.

Edit
Nevermind this is already implemented in wasmparser crate

<img width="302" height="239" alt="Image" src="https://github.com/user-attachments/assets/88b8ae9b-b5ed-4baf-bf9c-be6939b04237" />

Wasmtime GitHub notifications bot (Feb 19 2026 at 20:02):

alexcrichton closed issue #11572:

We're hoping to migrate from wasmer to wasmtime but we need fine grained control over fuel consumption based on a per wasm operator usage pattern.

In wasmer we can set a tunable cost function and then use a metering middleware function.

The cost function itself might look something like......

fn cost_function(operator: &Operator) -> u64 {
    match operator {
        Operator::LocalGet { .. } | Operator::I32Const { .. } => 2,
        Operator::I32Add { .. } => 4,
        _ => 1,
    }
}

Is something like this possible in wasmtime.

Thank you for this great project.

Last updated: Feb 24 2026 at 05:28 UTC