Stream: git-wasmtime

Topic: wasmtime / PR #13394 Reimplement passive data segments

Wasmtime GitHub notifications bot (May 16 2026 at 00:02):

alexcrichton opened PR #13394 from alexcrichton:reimplement-passive-data-segments to bytecodealliance:main:

This commit refactors and reimplements how passive data segments are implemented in Wasmtime. The goal of this commit is to push towards #13387 where bulk operations are done in wasm and have fuel/epoch checks as appropriate. A secondary goal here is to continue to reduce the number of libcalls we have and push more of the implementation into Cranelift-generated code.

The set of dropped data segments is removed from vm::Instance and conceptually moved to VMContext. A new area of the VMContext is initialized with an entry-per-passive-data-segment which contains the current length of the data segment, either 0 or the initial length. This is then used to fully implement memory.init, array.new_data, and array.init_data within Cranelift-generated code. The bounds check happens entirely in wasm now. Preexisting libcalls were all removed and the only remaining libcall is a new one to acquire the host's data pointer for a passive data segment. Combining all of this together all of these instructions can now use the memory_copy libcall in the same manner as other instructions, narrowing the funnel of "bulk data copy" instructions.

<!--
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 (May 16 2026 at 00:02):

alexcrichton requested cfallin for a review on PR #13394.

Wasmtime GitHub notifications bot (May 16 2026 at 00:02):

alexcrichton requested wasmtime-compiler-reviewers for a review on PR #13394.

Wasmtime GitHub notifications bot (May 16 2026 at 00:02):

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

Wasmtime GitHub notifications bot (May 16 2026 at 00:12):

alexcrichton updated PR #13394.

Wasmtime GitHub notifications bot (May 16 2026 at 05:41):

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

Wasmtime GitHub notifications bot (May 16 2026 at 05:41):

github-actions[bot] added the label wasmtime:ref-types on PR #13394.

Wasmtime GitHub notifications bot (May 16 2026 at 05:42):

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

Subscribe to Label Action

cc @fitzgen

<details>
This issue or pull request has been labeled: "wasmtime:api", "wasmtime:ref-types"

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

• fitzgen: wasmtime:ref-types

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 (May 18 2026 at 17:22):

fitzgen commented on PR #13394:

(Haven't looked at the code yet, but)

the only remaining libcall is a new one to acquire the host's data pointer for a passive data segment.

Why not put the data segment's pointer into the vmctx too, so that we have ~effectively

struct VMContext {
    // ...
    passive_data: PrimaryMap<PassiveDataIndex, (NonNull<u8>, usize)>
    // ...
}

and then we wouldn't even need that last libcall?

Wasmtime GitHub notifications bot (May 18 2026 at 17:23):

fitzgen edited a comment on PR #13394:

(Haven't looked at the code yet, but)

the only remaining libcall is a new one to acquire the host's data pointer for a passive data segment.

Why not put the data segment's pointer into the vmctx too, so that we have ~effectively

struct VMContext {
    // ...
    passive_data: PrimaryMap<PassiveDataIndex, (NonNull<u8>, usize)>
    // ...
}

and then we wouldn't even need that last libcall?

Wasmtime GitHub notifications bot (May 18 2026 at 17:23):

fitzgen edited a comment on PR #13394:

(Haven't looked at the code yet, but)

the only remaining libcall is a new one to acquire the host's data pointer for a passive data segment.

Why not put the data segment's pointer into the vmctx too, so that we have ~effectively

struct VMContext {
    // ...
    passive_data: PrimaryMap<PassiveDataIndex, (NonNull<u8>, usize)>,
    // ...
}

and then we wouldn't even need that last libcall?

Wasmtime GitHub notifications bot (May 18 2026 at 18:14):

:memo: fitzgen submitted PR review:

(Holding off on approval until we talk through my other comment.)

Wasmtime GitHub notifications bot (May 18 2026 at 18:14):

:speech_balloon: fitzgen created PR review comment:

Small doc clarification:

/// Index type of a passive data segment inside the WebAssembly module.
///
/// Not a spec-level concept, just used to get dense index spaces for passive
/// data segments inside of Wasmtime.
#[derive(Copy, Clone, PartialEq, Eq, Hash, PartialOrd, Ord, Debug, Serialize, Deserialize)]

Wasmtime GitHub notifications bot (May 18 2026 at 21:37):

alexcrichton updated PR #13394.

Wasmtime GitHub notifications bot (May 18 2026 at 21:37):

alexcrichton updated PR #13394.

Wasmtime GitHub notifications bot (May 18 2026 at 21:37):

alexcrichton commented on PR #13394:

Oh, good point! I've refactored to do just that now.

Wasmtime GitHub notifications bot (May 18 2026 at 21:46):

:thumbs_up: fitzgen submitted PR review:

Probably better locality to put the base and index in a tuple in the same array, rather than have two arrays, since they are accessed together at the same time, but that would require a little more work and also padding I guess, so not a big deal and always something we can revisit. Thanks!

Wasmtime GitHub notifications bot (May 19 2026 at 04:44):

alexcrichton updated PR #13394.

Wasmtime GitHub notifications bot (May 19 2026 at 04:44):

alexcrichton has enabled auto merge for PR #13394.

Wasmtime GitHub notifications bot (May 19 2026 at 04:55):

alexcrichton added PR #13394 Reimplement passive data segments to the merge queue.

Wasmtime GitHub notifications bot (May 19 2026 at 05:20):

github-merge-queue[bot] removed PR #13394 Reimplement passive data segments from the merge queue.

Wasmtime GitHub notifications bot (May 19 2026 at 05:52):

alexcrichton updated PR #13394.

Wasmtime GitHub notifications bot (May 19 2026 at 05:52):

alexcrichton has enabled auto merge for PR #13394.

Wasmtime GitHub notifications bot (May 19 2026 at 06:00):

alexcrichton updated PR #13394.

Wasmtime GitHub notifications bot (May 19 2026 at 06:13):

alexcrichton added PR #13394 Reimplement passive data segments to the merge queue.

Wasmtime GitHub notifications bot (May 19 2026 at 06:38):

github-merge-queue[bot] removed PR #13394 Reimplement passive data segments from the merge queue.

Wasmtime GitHub notifications bot (May 19 2026 at 10:01):

github-actions[bot] added the label cranelift on PR #13394.

Wasmtime GitHub notifications bot (May 19 2026 at 21:54):

alexcrichton added PR #13394 Reimplement passive data segments to the merge queue.

Wasmtime GitHub notifications bot (May 19 2026 at 22:18):

:check: alexcrichton merged PR #13394.

Wasmtime GitHub notifications bot (May 19 2026 at 22:18):

alexcrichton removed PR #13394 Reimplement passive data segments from the merge queue.

Last updated: Jun 01 2026 at 09:49 UTC