Stream: git-wasmtime

Topic: wasmtime / PR #13841 Add a tunable knob for the GC heap i...


view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 16:35):

alexcrichton requested fitzgen for a review on PR #13841.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 16:35):

alexcrichton requested wasmtime-fuzz-reviewers for a review on PR #13841.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 16:35):

alexcrichton opened PR #13841 from alexcrichton:gc-heap-initial-size to bytecodealliance:main:

Splitting this out of #13822 with some fuzzing/testing integration, updated to be a Tunable field, and some edits to comments.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 16:35):

alexcrichton requested wasmtime-core-reviewers for a review on PR #13841.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 16:57):

:thumbs_up: fitzgen submitted PR review:

Can we have a test for what happens when the gc heap's initial size is larger than the gc heap reservation?

Also, making the default larger than zero (and derived from the heap reservation) could be good because even if we've already reserved the space we will do collections on the way to growing the GC heap to fill that pre-reserved space, and that can make things much slower than they'd otherwise be.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 16:57):

:speech_balloon: fitzgen created PR review comment:

This should maybe link to Collector::Copying or something. Or maybe we should put the canonical "this collector splits the heap in half" note there, and just link to it from here in an "fyi ..." kind of way.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 16:57):

:speech_balloon: fitzgen created PR review comment:

    /// The `bytes` size is rounded up to the GC heap's page size. Also note

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 17:12):

alexcrichton updated PR #13841.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 17:15):

alexcrichton updated PR #13841.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 17:17):

alexcrichton commented on PR #13841:

Can we have a test for what happens when the gc heap's initial size is larger than the gc heap reservation?

Sure yeah, but I'll note that this behavior works ok, and is expected to work ok. This is how linear memories work at least.

This should maybe link to Collector::Copying or something

I just removed the docs, not worth worrying much about as it's just duplicating info.

Also, making the default larger than zero (and derived from the heap reservation)

I'm a bit hesitant to do this myself based on the impact it'll have on the resource limiter invocations. What are you thinking though? Are you thinking that the initial size sould be reservation/2 or something like that?

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 18:23):

github-actions[bot] added the label fuzzing on PR #13841.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 18:23):

github-actions[bot] added the label wasmtime:api on PR #13841.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 18:23):

github-actions[bot] added the label wasmtime:config on PR #13841.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 18:24):

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

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:

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

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 19:07):

tschneidereit commented on PR #13841:

FWIW I didn't make this a tunable because it doesn't impact compilation, as I think the other tunables do. It seems like it'd be nice to be able to tweak this without invalidating compiled artifacts, which I don't know if that still works if it's a tunable.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 19:11):

alexcrichton commented on PR #13841:

Oh I commented over here but this does affect compilation w.r.t. static offsets and such. Given how subtle MemoryType and its handling is (and historical mistakes have been CVEs-in-waiting) I'd want to keep everything pretty centralized (e.g. the inline update to Tunables::gc_heap_memory_type). Having a separate tunable for "don't optimize based on minimum memory size" seems reasonable to have and at that point would mean we wouldn't need to compare the tunable during deserialization

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 19:20):

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

Label Messager: wasmtime:config

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

[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>

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 19:27):

tschneidereit commented on PR #13841:

Oh, I had seen that comment, but skimmed over the part relevant to this—apologies!

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 19:29):

fitzgen commented on PR #13841:

I'm a bit hesitant to do this myself based on the impact it'll have on the resource limiter invocations. What are you thinking though? Are you thinking that the initial size sould be reservation/2 or something like that?

reservation/4 maybe? That gives us 2 doubling-growths and opportunities for the resource limiter to push back before reaching the initial heap reservation.

But also, this can happen in a follow up, no need to block this PR on an existing thing.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 19:30):

fitzgen added PR #13841 Add a tunable knob for the GC heap initial size to the merge queue.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 20:18):

github-merge-queue[bot] removed PR #13841 Add a tunable knob for the GC heap initial size from the merge queue.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 21:31):

alexcrichton updated PR #13841.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 21:31):

alexcrichton has enabled auto merge for PR #13841.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 21:43):

alexcrichton added PR #13841 Add a tunable knob for the GC heap initial size to the merge queue.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 22:01):

github-merge-queue[bot] removed PR #13841 Add a tunable knob for the GC heap initial size from the merge queue.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 22:17):

alexcrichton added PR #13841 Add a tunable knob for the GC heap initial size to the merge queue.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 22:48):

:check: alexcrichton merged PR #13841.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2026 at 22:48):

alexcrichton removed PR #13841 Add a tunable knob for the GC heap initial size from the merge queue.


Last updated: Jul 29 2026 at 05:03 UTC