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.

Last updated: Dec 06 2025 at 06:05 UTC