Stream: wasmtime

Topic: Feature request: Batched fuel consumption at basic block gra

Aarav Dayal (Nov 29 2025 at 09:12):

Hello! I am working on my own virtual machine and have a question about how fuel consumption is currently implemented and a feature request regarding the same.

From my research I understand that:

• Fuel checks happen at control flow boundaries (function entry, loop headers)
• Fuel consumption happens per WebAssembly operator (most operators consume 1 unit)
• This per-operator consumption creates performance overhead

I would prefer if something like this could be implemented in wasmtime:

// Instead of:
instruction_1
  consume_fuel(1)
instruction_2
  consume_fuel(1)
instruction_3
  consume_fuel(1)

// It would be better if it was something like:
instruction_1
instruction_2
instruction_3
  consume_fuel(3)  // Batch at end of basic block

This would reduce the number of increment operations while still allowing fuel checks at control flow boundaries to interrupt execution when needed.

Questions

1. Is this kind of batched fuel consumption currently possible with any configuration?
2. Has this been considered before? (I saw issue #4109 about "slacked fuel metering" but I'm not sure if that's the same thing)
3. Would this be feasible to implement in Cranelift's code generation, or are there fundamental reasons why per-operator consumption is necessary?

Dave Bakker (badeend) (Nov 29 2025 at 16:58):

You may be interested in epoch-based interruption:

Epoch-based interruption imposes relatively low overhead on Wasm execution; it has been measured at around a 10% slowdown. It is faster than fuel-based interruption.

Aarav Dayal (Nov 29 2025 at 23:37):

Dave Bakker (badeend) said:

You may be interested in epoch-based interruption:

Epoch-based interruption imposes relatively low overhead on Wasm execution; it has been measured at around a 10% slowdown. It is faster than fuel-based interruption.

I am interested in deterministic fuel metering.

Alex Crichton (Nov 30 2025 at 00:00):

I believe that this sort of batching is already implemented. The code looks like it's consume-per-op but IIRC it batches up the actual increment until some sort of side-effecting thing happens. Once a side-effecting thing happens though (e.g. loads/stores) for the determinism of fuel it needs to be flushed.

Having a tunable option for ignoring side effecting ops other than control flow might be a possibility though

Aarav Dayal (Nov 30 2025 at 00:14):

Are you sure that wasmtime batches instruction increments?

Last updated: Dec 06 2025 at 06:05 UTC