Skip to content

Optionally charge lifted hostcall fuel against store fuel - #15104

Open
RajaBabu15 wants to merge 1 commit into
bytecodealliance:mainfrom
RajaBabu15:hostcall-fuel-store-fuel
Open

RajaBabu15 wants to merge 1 commit into
bytecodealliance:mainfrom
RajaBabu15:hostcall-fuel-store-fuel

Conversation

@RajaBabu15

Copy link
Copy Markdown

Closes #14430

Implements the approach agreed in the issue: optionally charge Store fuel for the work done while lifting guest values into the host, at LiftContext::consume_fuel.

  • New opt-in Store::set_hostcall_fuel_consumes_store_fuel(bool) (plus getter and StoreContextMut mirrors). Off by default; only has an effect with Config::consume_fuel(true).
  • When enabled, each unit of hostcall fuel consumed during a lift also consumes one unit of Store fuel, charged before the copy happens. If Store fuel runs out, the remaining fuel is consumed and the lift traps with Trap::OutOfFuel. Charges already made earlier in the same lift stay charged.
  • Lowering is not charged, per the discussion. Hostcall fuel consumed in compiled FACT adapters / component-to-component streams (Consume hostcall fuel in FACT adapters & streams #15030) is also not charged here.
  • The fuel math reuses the existing get_fuel/set_fuel helpers. A charge that fits in the active (injected) window only bumps that counter, leaving the reserve and the async yield cadence alone.
  • When the flag is off, the only cost is one Option check in consume_fuel.

Tests:

  • tests/all/component_model/import.rs: flag off (default), flag on, flag on with too little fuel (OutOfFuel, fuel is 0, host fn never runs), and flag on without Config::consume_fuel.
  • Unit tests for the new fuel helper in runtime/store.rs.
  • Locally on aarch64 macOS: component_model (264), fuel (75) and wasmtime --lib (183) tests pass; fmt and clippy are clean. The C API was not built locally (no cmake).

Open questions:

  1. Naming, and whether this belongs on Store (next to set_hostcall_fuel) or on Config.
  2. The setter is currently a silent no-op without Config::consume_fuel; should it return an error like set_fuel does?
  3. If one charge is larger than the active fuel window, the remaining fuel is redistributed, which restarts the async-yield countdown. Is that acceptable, or should it leave the counter positive so the next wasm fuel check handles it?

🤖 Generated with Claude Code

@RajaBabu15
RajaBabu15 requested a review from a team as a code owner October 31, 2026 22:30
@RajaBabu15
RajaBabu15 requested review from fitzgen and removed request for a team October 31, 2026 22:30
@github-actions github-actions Bot added the wasmtime:api Related to the API of the `wasmtime` crate itself label Nov 1, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

wasmtime:api Related to the API of the `wasmtime` crate itself

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Accounting for component conversion work in an execution fuel budget

1 participant