Stream: git-wasmtime

Topic: wasmtime / PR #12507 Add a fallible-allocation-only `Hash...

Wasmtime GitHub notifications bot (Feb 03 2026 at 19:47):

fitzgen opened PR #12507 from fitzgen:fallible-alloc-only-hash-tables to bytecodealliance:main:

Part of https://github.com/bytecodealliance/wasmtime/issues/12069

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Feb 03 2026 at 19:47):

fitzgen requested wasmtime-fuzz-reviewers for a review on PR #12507.

Wasmtime GitHub notifications bot (Feb 03 2026 at 19:47):

fitzgen requested wasmtime-core-reviewers for a review on PR #12507.

Wasmtime GitHub notifications bot (Feb 03 2026 at 19:47):

fitzgen requested wasmtime-default-reviewers for a review on PR #12507.

Wasmtime GitHub notifications bot (Feb 03 2026 at 19:47):

fitzgen requested alexcrichton for a review on PR #12507.

Wasmtime GitHub notifications bot (Feb 03 2026 at 19:54):

alexcrichton created PR review comment:

.saturating_mul(size_of::<T>())

Wasmtime GitHub notifications bot (Feb 03 2026 at 19:54):

alexcrichton created PR review comment:

Could this use std::collections when the std feature is enabled?

Wasmtime GitHub notifications bot (Feb 03 2026 at 19:54):

alexcrichton submitted PR review:

High level question: do hash-based collections really provide a guarantee that if you reserve(1) the next insertion will never allocate? My naive intuition is that there'd be niche cases where reallocation might still happen, for example if some chain of hash collisions gets too long it's reallocated or something like that. Reading over libstd's documentation it doesn't read to me like it's a 100% strict guarantee per se, instead mostly being related to allocation amortization.

Wasmtime GitHub notifications bot (Feb 03 2026 at 20:07):

fitzgen commented on PR #12507:

High level question: do hash-based collections really provide a guarantee that if you reserve(1) the next insertion will never allocate? My naive intuition is that there'd be niche cases where reallocation might still happen, for example if some chain of hash collisions gets too long it's reallocated or something like that. Reading over libstd's documentation it doesn't read to me like it's a 100% strict guarantee per se, instead mostly being related to allocation amortization.

Yeah, I am vaguely concerned here as well, because I am also not sure about the actual hard guarantees we are given. But also neither std or hashbrown give us a try_insert et al family of methods, so I figure we can just do our best for now, and rewrite code to use something else (handwaves) if it becomes a problem down the line.

Wasmtime GitHub notifications bot (Feb 03 2026 at 20:07):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Feb 03 2026 at 20:07):

fitzgen created PR review comment:

You mean swap out all of hashbrown for std?

Wasmtime GitHub notifications bot (Feb 03 2026 at 20:09):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Feb 03 2026 at 20:09):

alexcrichton created PR review comment:

Yeah, that's what we do in most other crates where when std is available we're always sure to use those collections and only no_std builds use hashbrown

Wasmtime GitHub notifications bot (Feb 03 2026 at 20:09):

alexcrichton submitted PR review:

Makes sense to me yeah, and agreed this is something we can tweak over time.

Wasmtime GitHub notifications bot (Feb 03 2026 at 20:11):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Feb 03 2026 at 20:11):

fitzgen created PR review comment:

wasmtime always uses hashbrown fwiw: https://github.com/bytecodealliance/wasmtime/blob/28f6f5e77bbe864b5b21e6fbe10053b04231f4b0/crates/wasmtime/src/lib.rs#L417

Wasmtime GitHub notifications bot (Feb 03 2026 at 20:38):

fitzgen updated PR #12507.

Wasmtime GitHub notifications bot (Feb 03 2026 at 20:39):

fitzgen has enabled auto merge for PR #12507.

Wasmtime GitHub notifications bot (Feb 03 2026 at 20:52):

fitzgen added PR #12507 Add a fallible-allocation-only HashSet to wasmtime_environ::collections to the merge queue

Wasmtime GitHub notifications bot (Feb 03 2026 at 21:01):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Feb 03 2026 at 21:01):

alexcrichton created PR review comment:

Oh dear we should fix that... I'll queue that up

Wasmtime GitHub notifications bot (Feb 03 2026 at 21:16):

fitzgen merged PR #12507.

Wasmtime GitHub notifications bot (Feb 03 2026 at 21:17):

fitzgen removed PR #12507 Add a fallible-allocation-only HashSet to wasmtime_environ::collections from the merge queue

Last updated: Feb 24 2026 at 04:36 UTC