fuel: Defer fuel consumption for bulk operations - #14213
Conversation
For bulk operations and table/memory grows, wait until the operation has succeeded to consume fuel. This prevents large operations that fail from consuming fuel for work that doesn't actually occur.
| i32.const 0 | ||
| i32.const 65536 | ||
| memory.copy | ||
| (loop) |
There was a problem hiding this comment.
Since we're now consuming the fuel after the fuel check, a bunch of these tests need an additional fuel check inserted at the end to pass. The empty loop block does that.
There was a problem hiding this comment.
Could the fuel check move to after the operation instead of before the operation to handle this? That way while the fuel running out would be retroactively discovered it'd basically be the same thing and wouldn't need extra updates
There was a problem hiding this comment.
Yeah we can do that. I think it'll require changing some other tests which assert that we don't do a bulk operation if fuel is at 0 just before the op, but that seems fine to me.
There was a problem hiding this comment.
Yeah that seems ok to me, a lot of the fuel tests are about precise behavior and it's ok to tweak them if the behavior is slightly adjusted as well
|
|
||
| #[wasmtime_test(wasm_features(memory64), strategies(not(Winch)))] | ||
| #[cfg_attr(miri, ignore)] | ||
| fn memory64_variable_operator_cost_saturates(config: &mut Config) -> Result<()> { |
There was a problem hiding this comment.
I'm not sure what to do with these saturating fuel tests. Now that we only consume the fuel on a successful operation we shouldn't be able to actually hit the saturation.
2 participants
For bulk operations and memory/table grows, defer consuming fuel until the operation has succeed.
This fixes #14161.
For small statically known sizes, we immediately consume fuel, but for larger or dynamic sizes we insert a fuel/epoch check before the operation and then only consume the variable fuel amount after.