wasmtime / PR #10619 Minimal implementation of fixed size... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #10619 Minimal implementation of fixed size...

Wasmtime GitHub notifications bot (Apr 20 2025 at 19:34):

cpetig opened PR #10619 from cpetig:fixed-size-list to bytecodealliance:main:

Implement the necessary parts of fixed size lists (see https://github.com/WebAssembly/component-model/pull/384 ) to enable runtime testing in wit-bindgen.

Wasmtime GitHub notifications bot (Apr 20 2025 at 20:45):

github-actions[bot] commented on PR #10619:

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.

<details>

Our documentation should be of the following form:

```text
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.
```

</details>

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

<details>

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][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][fuzzing-docs] for more details.

</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.

[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html

<details>

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

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

Learn more.

</details>

Wasmtime GitHub notifications bot (Apr 21 2025 at 15:13):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Apr 21 2025 at 15:13):

alexcrichton created PR review comment:

Could this be done with a new helper? I'm wary of defining an O(n) thing here and relying on LLVM to optimize it. This could make list<T, BigNumber> excessively slow in debug builds of Wasmtime for example.

Wasmtime GitHub notifications bot (Apr 21 2025 at 15:13):

alexcrichton created PR review comment:

Same as above, I think it'd be best to avoid "feigning" a record here and using a dedicated computation for fixed-size lists to avoid O(n) in the length of the list

Wasmtime GitHub notifications bot (Apr 21 2025 at 15:13):

alexcrichton created PR review comment:

Since these are relatively targeted todo!() items mind filing an issue as a tracking issue and tagging these with // FIXME(#NNNN)?

Wasmtime GitHub notifications bot (Apr 21 2025 at 15:13):

alexcrichton created PR review comment:

This is a bit of an interesting case. Effectively what this is doing is unrolling list<T, N> unconditionally, but I don't think that's necessarily appropriate for large N. I think it's fine to unroll for small N (perhaps only when T is small?). Ideally this would have a budget of sorts where a fixed number Cost is divided by the cost of T , and that's the maximal unrolling. That way we don't generate exponential amounts of code here for list<list<T, N>, N>.

Basically what I'm saying is that I think we must implement the loop-based variant of translating lists, not just the fully-unrolled version of translating lists.

Wasmtime GitHub notifications bot (Jul 12 2025 at 15:37):

cpetig updated PR #10619.

Wasmtime GitHub notifications bot (Jan 07 2026 at 22:42):

cpetig updated PR #10619.

Wasmtime GitHub notifications bot (Jan 07 2026 at 23:57):

cpetig updated PR #10619.

Wasmtime GitHub notifications bot (Jan 08 2026 at 00:00):

cpetig updated PR #10619.

Wasmtime GitHub notifications bot (Jan 08 2026 at 00:01):

cpetig submitted PR review.

Wasmtime GitHub notifications bot (Jan 08 2026 at 00:01):

cpetig created PR review comment:

See https://github.com/bytecodealliance/wasmtime/issues/12279

Wasmtime GitHub notifications bot (Jan 08 2026 at 00:03):

cpetig submitted PR review.

Wasmtime GitHub notifications bot (Jan 08 2026 at 00:03):

cpetig created PR review comment:

This takes a bit more effort, I will complete this later.

Wasmtime GitHub notifications bot (Jan 10 2026 at 12:28):

cpetig updated PR #10619.

Wasmtime GitHub notifications bot (Jan 11 2026 at 20:50):

cpetig updated PR #10619.

Wasmtime GitHub notifications bot (Jan 11 2026 at 20:56):

cpetig has marked PR #10619 as ready for review.

Wasmtime GitHub notifications bot (Jan 11 2026 at 20:57):

cpetig requested pchickey for a review on PR #10619.

Wasmtime GitHub notifications bot (Jan 11 2026 at 20:57):

cpetig requested wasmtime-core-reviewers for a review on PR #10619.

Wasmtime GitHub notifications bot (Jan 11 2026 at 21:18):

cpetig commented on PR #10619:

The best test for this functionality are the tests added to wit-bindgen in https://github.com/bytecodealliance/wit-bindgen/pull/1277 .

I can create a test for this one as well (I didn't find a good template in the existing tests), but perhaps it makes most sense to introduce tests together with the host support in #12315 .

Wasmtime GitHub notifications bot (Jan 12 2026 at 16:26):

alexcrichton created PR review comment:

Question for you (sorry it's been awhile since I looked at this) -- is there a validation predicate in wasm-tools to ensure that this multiplication doesn't overflow?

Wasmtime GitHub notifications bot (Jan 12 2026 at 16:26):

alexcrichton submitted PR review:

Would it be possible to add a sample *.wast test which exercises this?

Wasmtime GitHub notifications bot (Jan 12 2026 at 16:26):

alexcrichton created PR review comment:

This sould be an .and_then I think, right? Plus a checked_mul and/or try_into?

Wasmtime GitHub notifications bot (Jan 12 2026 at 16:44):

cpetig submitted PR review.

Wasmtime GitHub notifications bot (Jan 12 2026 at 16:44):

cpetig created PR review comment:

I don't think so, so its probably better to use a saturating multiply here. I don't think that making the function fallible is worth the effort?

Wasmtime GitHub notifications bot (Jan 12 2026 at 16:48):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jan 12 2026 at 16:48):

alexcrichton created PR review comment:

Hm ok I agree that this doesn't need to be fallible, but we should probably add a reasonable size limits in wasm-tools as well, e.g. 1G or something like that, to ensure that calculations don't overflow

Wasmtime GitHub notifications bot (Jan 12 2026 at 16:56):

cpetig commented on PR #10619:

Would it be possible to add a sample *.wast test which exercises this?

I guess it would be possible to make a two sub-component example which externally only offers a single boolean returning function, anything beyond this will depend on https://github.com/bytecodealliance/wasmtime/pull/12315 (e.g. passing an array to a function and checking the round-trip result).

Judging from the amount of errors uncovered by a single wit-bindgen test I think list-minmax16: func(a: list<u16, 4>, b: list<s16, 4>) -> tuple<list<u16, 4>, list<s16, 4>>; is the signature to test here :wink: (arguments are on stack, result is in memory and the tuple exercises offsets)

Wasmtime GitHub notifications bot (Jan 12 2026 at 18:44):

alexcrichton commented on PR #10619:

That sounds reasonable to me yeah, and I think it's fine to expand the test coverage over time but I also think it'd be good to test what we can in this PR itself (which is, as you say, the composed-in-the-middle use)

Wasmtime GitHub notifications bot (Jan 12 2026 at 19:58):

cpetig requested fitzgen for a review on PR #10619.

Wasmtime GitHub notifications bot (Jan 12 2026 at 19:58):

cpetig requested wasmtime-fuzz-reviewers for a review on PR #10619.

Wasmtime GitHub notifications bot (Jan 12 2026 at 19:58):

cpetig updated PR #10619.

Wasmtime GitHub notifications bot (Jan 12 2026 at 20:01):

cpetig submitted PR review.

Wasmtime GitHub notifications bot (Jan 12 2026 at 20:01):

cpetig created PR review comment:

https://github.com/bytecodealliance/wasm-tools/issues/2416

Wasmtime GitHub notifications bot (Jan 12 2026 at 20:04):

cpetig submitted PR review.

Wasmtime GitHub notifications bot (Jan 12 2026 at 20:04):

cpetig created PR review comment:

element_abi.flat_count .zip(u8::try_from(size).ok()) .and_then(|(flat_count, size)| flat_count.checked_mul(size)) doesn't feel ideal, but should be closer to what you proposed.

Wasmtime GitHub notifications bot (Jan 12 2026 at 20:07):

cpetig commented on PR #10619:

I added a moderately readable test (created in C++, then stripped down to 400 lines of wat).

Though, I was unable to get ;;! component_model_fixed_size_lists = true recognized by the wast test runner.

Could it be that it usually sets properties according to the path of the test? Or is it supposed to work and I just missed something?

Wasmtime GitHub notifications bot (Jan 12 2026 at 20:17):

cpetig commented on PR #10619:

Oh, that is a new to me error in CI:

thread '<unnamed>' (24806) panicked at crates/environ/src/component/translate/adapt.rs:245:14:
invalid adapter module generated: multiple memories (at offset 0x5d)

I guess I need to take a deeper look tomorrow.

Wasmtime GitHub notifications bot (Jan 12 2026 at 20:20):

cpetig edited a comment on PR #10619:

Oh, that is a new to me error in CI:

thread '<unnamed>' (24806) panicked at crates/environ/src/component/translate/adapt.rs:245:14:
invalid adapter module generated: multiple memories (at offset 0x5d)

I guess I need to take a deeper look tomorrow.

PS: The error on my computer is

Error: failed to run script file 'fixed_size_list.wast'

Caused by:
    0: failed directive on fixed_size_list.wast:17
    1: failed to parse WebAssembly module
    2: Fixed size lists require the component model fixed size list feature (at offset 0x16)

wasmtime wast -W component-model-fixed-size-lists fixed_size_list.wast works for me...

Wasmtime GitHub notifications bot (Jan 12 2026 at 21:08):

alexcrichton commented on PR #10619:

Oh for that you'll want to add multi_memory = true at the top of the file. Not needed on the CLI because that inherits the default feature set, but during tests we turn off all features and require them to be explicitly turned on in files

Wasmtime GitHub notifications bot (Jan 12 2026 at 22:46):

github-actions[bot] commented on PR #10619:

Subscribe to Label Action

cc @fitzgen

<details>
This issue or pull request has been labeled: "fuzzing", "wasmtime:api", "wasmtime:config"

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

fitzgen: fuzzing

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

Learn more.
</details>

Wasmtime GitHub notifications bot (Jan 13 2026 at 15:54):

cpetig commented on PR #10619:

Oh for that you'll want to add multi_memory = true at the top of the file. Not needed on the CLI because that inherits the default feature set, but during tests we turn off all features and require them to be explicitly turned on in files

My assumption was that this is caused by the component to component copying code https://github.com/bytecodealliance/wasmtime/pull/10619/files#diff-32f96d31ce61f8177ede00faf17bc565a8d15a00d42eb20b28a948a7a257dd87R2885-R2953 - I would assume that all adapters need multi-memory to work.

Wasmtime GitHub notifications bot (Jan 13 2026 at 21:01):

cpetig updated PR #10619.

Wasmtime GitHub notifications bot (Jan 13 2026 at 21:03):

cpetig commented on PR #10619:

My assumption was that this is caused by the component to component copying code https://github.com/bytecodealliance/wasmtime/pull/10619/files#diff-32f96d31ce61f8177ede00faf17bc565a8d15a00d42eb20b28a948a7a257dd87R2885-R2953 - I would assume that all adapters need multi-memory to work.

I was looking for wasmtime wast to pick up the setting and didn't realize that the test runner takes care of this. Should work now. Thank you for the tip, Alex.

Wasmtime GitHub notifications bot (Jan 13 2026 at 21:29):

cpetig updated PR #10619.

Wasmtime GitHub notifications bot (Jan 13 2026 at 21:31):

cpetig commented on PR #10619:

:blush: Oh, I took a look whether "fixed-size-list" or "fixed-size-lists" is the name in the component spec, it is "fixed-length lists". So, I made sure that wasmtime adheres to the standard name.

Whether/how to change wasm-tools will be a separate discussion.

Wasmtime GitHub notifications bot (Jan 13 2026 at 21:39):

cpetig updated PR #10619.

Last updated: Feb 24 2026 at 05:28 UTC