Add Config::fuel_cost to customize fuel cost func

[coolreader18]

Adds Config::fuel_cost as described in #5109. I'm not sure where test cases for fuel are, if they exist?

[github-actions]

Subscribe to Label Action

cc @peterhuene

This issue or pull request has been labeled: "wasmtime:api", "wasmtime:config"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[github-actions]

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

• If you added a new Config method, you wrote extensive documentation for
  it.

  Our documentation should be of the following form:

  Short, simple summary sentence.
  
  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.
  
  Is this method fallible? If so, when can it return an error?
  
  Can this method panic? If so, when does it panic?
  
  # Example
  
  Optional example here.
  

• If you added a new Config method, or modified an existing one, you
  ensured that this configuration is exercised by the fuzz targets.

  For example, if you expose a new strategy for allocating the next instance
  slot inside the pooling allocator, you should ensure that at least one of our
  fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this
  configuration option in wasmtime_fuzzing::Config (or one
  of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this
  configuration. See our docs on fuzzing for more details.

• If you are enabling a configuration option by default, make sure that it
  has been fuzzed for at least two weeks before turning it on by default.

---

To modify this label's message, edit the .github/label-messager/wasmtime-config.md file.

To add new label messages or remove existing label messages, edit the
.github/label-messager.json configuration file.

Learn more.

[coolreader18]

Hmm, should I use saturating_add for adding self.fuel_cost += fuel_cost()? An overflow there would probably be bad, I assume.

[pepyakin]

I wonder how this interacts with the AOT compilation.

Consider that the user creates the engine with a specific fuel cost function, then loads a module, and then serializes it into a file.

Then, perhaps in another version of the program, changes the fuel cost function and loads the previously serialized module. However, the fuel behavior that the loaded module exhibits will be different from the configured fuel costs. I would argue that this is an unexpected behavior. At the very least, I would expect to get an error during the module loading.

To do so, the metadata for the compiled artifact should embed the module costs, but that's not really possible with a closure.

It seems to me that the costs schedule would better be represented, conceptually, by a BTreeMap<Opcode, u32>. That way, you could serialize and embed them into the compiled artifact.

[alexcrichton]

Thanks for the PR here! Could you expand a bit more on the use case that you're envisioning for this? This is a pretty low-level degree of control to give from an embedding API around fuel and feels like a relatively large addition with the enum addition here (not that there's a better way to model this that I know of). I'm curious though if there's perhaps an alternative solution which doesn't expose such low-level control of the fuel costs, but there may not be.

I would also be slightly concerned about the AOT-story here since in theory the costs all need to be equivalent, but that can also be "patched" by returning an error and disabling serialization if this Config field is configured.

[coolreader18]

Oh, I missed that Module::deserialize checks that the engine configs are the same; those are good points about AOT. Maybe fuel_cost() could take a data structure like rust-unic's CharDataTable or something.

In any case, the motivating use case was switching an existing runtime from wasmer, which has cost customization by default as part of its metering instrumentation and so we were utilizing that. I suppose it is worth looking into how valuable that actually is, when obviously the wasm doesn't map one-to-one to machine code anyway...

[alexcrichton]

Ok makes sense. I think we could have a compiled representation of the costs but that's somewhat overkill and probably not worth implementing. That's one reason why I was wondering what the purpose was for changing costs because if the default wasn't suitable for your use case one option is to either change the defaults or otherwise have various discrete cost modes which would avoid serializing large maps.

[coolreader18]

That makes sense, I'll look at sketching out a simpler (configuration-wise) solution to this or probably just reworking fuel usage in our codebase. Thank you for your help!

[jameysharp]

In case you haven't already seen it, I'll mention that Wasmtime's "epoch interruption" may be a good alternative to fuel, depending on what you're using it for. From the documentation:

In general, epoch-based interruption results in faster execution. This difference is sometimes significant: in some measurements, up to 2-3x. This is because epoch-based interruption does less work: it only watches for a global rarely-changing counter to increment, rather than keeping a local frequently-changing counter and comparing it to a deadline.

Fuel, in contrast, should be used when deterministic yielding or trapping is needed. For example, if it is required that the same function call with the same starting state will always either complete or trap with an out-of-fuel error, deterministically, then fuel with a fixed bound should be used.