Stream: git-wasmtime

Topic: wasmtime / PR #11364 optimize host stream/future writes f...

Wasmtime GitHub notifications bot (Jul 31 2025 at 18:36):

dicej requested alexcrichton for a review on PR #11364.

Wasmtime GitHub notifications bot (Jul 31 2025 at 18:36):

dicej opened PR #11364 from dicej:optimize-flat-lowerings to bytecodealliance:main:

When we know statically that a payload will not require any guest realloc calls to lower, there's no need to defer the lowering to a fiber -- we can just do it immediately.

<!--
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 (Jul 31 2025 at 18:36):

dicej requested wasmtime-core-reviewers for a review on PR #11364.

Wasmtime GitHub notifications bot (Jul 31 2025 at 18:39):

dicej commented on PR #11364:

One possible hole in this is that LowerContext::options is a public field, so someone could call options.realloc directly without going through LowerContext::realloc if they wanted (e.g. in a custom Lower implementation). Do we need to address that? If so, I could refactor some code so that we clone the options and null out the realloc function before passing it to LowerContext.

Wasmtime GitHub notifications bot (Jul 31 2025 at 18:46):

alexcrichton submitted PR review:

One possible hole in this is that LowerContext::options is a public field

I think that's ok because Options::realloc is a private method. It's possible to overwrite Options with something else which could be problematic, but this is just something for debug assertions and avoiding panics, not safety, so I think it's ok to ignore this.

Wasmtime GitHub notifications bot (Jul 31 2025 at 18:46):

alexcrichton created PR review comment:

Could this be renamed to MAY_REQUIRE_REALLOC? This otherwise isn't a guarantee that can be relied on as it's only set for integers, but it's not set for aggregates of other flat types (e.g. option-of-enum, etc).

Also can you add documentation that getting this correct is required for not panicking? Basically how other parts of the codebase will, for example, skip fibers during lowering if "may require realloc" is false

Wasmtime GitHub notifications bot (Jul 31 2025 at 18:47):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 31 2025 at 19:20):

dicej updated PR #11364.

Wasmtime GitHub notifications bot (Jul 31 2025 at 20:02):

dicej merged PR #11364.

Last updated: Dec 06 2025 at 06:05 UTC