chore: update wasmtime

[Stebalien]

No description provided.

[Stebalien]

We don't yet have an explicit limit on the number of table elements. We do limit it based on the available memory, but we likely need a max table elements limit defined in a FIP (not an issue right now, but a potential issue in the future.

[codecov-commenter]

Codecov Report

Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (f4b5f29) 75.53% compared to head (bd6863d) 75.59%.
Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1993      +/-   ##
==========================================
+ Coverage   75.53%   75.59%   +0.06%     
==========================================
  Files         158      157       -1     
  Lines       15600    15741     +141     
==========================================
+ Hits        11784    11900     +116     
- Misses       3816     3841      +25     

Files	Coverage Δ
fvm/src/engine/mod.rs	85.21% <100.00%> (+1.12%)	⬆️
ipld/amt/src/node.rs	86.16% <100.00%> (-0.50%)	⬇️
ipld/bitfield/src/iter/mod.rs	99.74% <ø> (ø)
ipld/hamt/src/lib.rs	100.00% <ø> (ø)
shared/src/address/mod.rs	92.72% <100.00%> (ø)
shared/src/econ/mod.rs	90.90% <100.00%> (ø)
fvm/src/blockstore/buffered.rs	82.29% <50.00%> (-0.23%)	⬇️
ipld/hamt/src/node.rs	89.81% <50.00%> (-0.22%)	⬇️
ipld/kamt/src/node.rs	81.80% <50.00%> (-0.13%)	⬇️
sdk/src/message.rs	0.00% <0.00%> (ø)

... and 50 files with indirect coverage changes

[Stebalien]

likely unnecessary, but I might as well.

[Stebalien]

This seems to sync mainnet.

[rvagg]

I'm currently looking at this, but dong some due diligence on how we currently configure and run it and what the delta is between wasmtime 12 and 17.

[rvagg]

This is a bit sad; I haven't looked at wasm-instrument yet but this shouldn't be a big deal to enable should it? just lots of instructions and everything at 128 bits.

[Stebalien]

It wouldn't be a huge deal, we just kept it disabled out of safety and haven't had the chance to test and benchmark it.

[rvagg]

We seem to be doing explicit config in here, reiterating all of the available and relevant options and setting custom defaults. If that's the aim, there's some that are not set here that we might want to consider?

• static_memory_forced since we set static_memory_maximum_size to max memory I guess we implicitly want this to be true so maybe be explicit about it?
• static_memory_guard_size assuming we're not supporting 32-bit runtimes, we're getting 2GB of this as a default (so a total of 8GB virtual address space per instance cause we have the before guard set already).
• dynamic_memory_guard_size is 64K by default, but maybe it only needs to be 0 since we're doing static=max?
• dynamic_memory_reserved_for_growth defaults to 2GB on 64-bit, but maybe could be 0?

[rvagg]

👍 seems like the big ticket items in the update are memory related and the default enablement of proposed extensions (that all complicate things for our use case!) that have been already explicitly disabled here.

[Stebalien]

We seem to be doing explicit config in here, reiterating all of the available and relevant options and setting custom defaults.

It's mostly to ensure that features we don't want remain off.

static_memory_forced

Good idea, implemented.

static_memory_guard_size

This shouldn't affect consensus, so I'm going to leave it at the default for now. Although we should consider 4GiB for performance.

dynamic_memory_*

I think we can ignore these if we force static memory.

[Stebalien]

Tested on mainnet and it still works.