Wasmtime GitHub notifications bot (Dec 10 2025 at 22:36): Wasmtime GitHub notifications bot (Dec 10 2025 at 22:36):dicej requested alexcrichton for a review on PR #12153.
Wasmtime GitHub notifications bot (Dec 10 2025 at 22:36):dicej opened PR #12153 from dicej:fix-12128 to bytecodealliance:main:
The spec says we should allow this, so now we do.
Thansk to Alex for the test case!
Fixes #12128
<!--
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.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Dec 10 2025 at 22:36):dicej requested wasmtime-core-reviewers for a review on PR #12153.
Wasmtime GitHub notifications bot (Dec 10 2025 at 22:45):alexcrichton submitted PR review:
Code/test all look fine, but I'm trying to correlate this with the spec as well. I thought I remember that historically
may_enterwas a thing but it's no longer present inCanonicalABI.md. Can you clarify which point in the spec I should be looking at to double-check this? (and probably queue up some sort of rename/refactor to handlemay_enterto align with the spec)
Wasmtime GitHub notifications bot (Dec 10 2025 at 22:53):Code/test all look fine, but I'm trying to correlate this with the spec as well. I thought I remember that historically
may_enterwas a thing but it's no longer present inCanonicalABI.md. Can you clarify which point in the spec I should be looking at to double-check this? (and probably queue up some sort of rename/refactor to handlemay_enterto align with the spec)Search for
trap_of_on_the_stackinCanonicalABI.mdand the prose that follows. I agree that some renaming and/or refactoring may be due.
Wasmtime GitHub notifications bot (Dec 10 2025 at 22:53):dicej edited a comment on PR #12153:
Code/test all look fine, but I'm trying to correlate this with the spec as well. I thought I remember that historically
may_enterwas a thing but it's no longer present inCanonicalABI.md. Can you clarify which point in the spec I should be looking at to double-check this? (and probably queue up some sort of rename/refactor to handlemay_enterto align with the spec)Search for
trap_if_on_the_stackinCanonicalABI.mdand the prose that follows. I agree that some renaming and/or refactoring may be due.
Wasmtime GitHub notifications bot (Dec 10 2025 at 23:00):I'm investigating the test failure; looks like dropping a subtask while it's yielding in an infinite loop will require some extra care.
Wasmtime GitHub notifications bot (Dec 11 2025 at 12:11):alexcrichton commented on PR #12153:
Joel and I discussed this and the conclusion is that the
may_enterhandling in Wasmtime is outdated and no longer in sync with the spec after component-model-async refactors. Effectively we need to rebuild the reentrance check from scratch throughout Wasmtime and avoid usingmay_enterfor the triple-purpose of: preventing reentrance, requiringpost_return, and lockdown-on-trap. This'll require refactors internally to use a new component-model-async helper but will have an impact on component adapter performance as well. This all corresponds totrap_if_on_the_stackin the spec (scroll down a bit)
Wasmtime GitHub notifications bot (Dec 11 2025 at 14:53):dicej edited a comment on PR #12153:
I'm investigating the test failure;
looks like dropping a subtask while it's yielding in an infinite loop will require some extra care.EDIT: the problem is more fundamental than that, and the refactoring Alex suggested above is going to be necessary in order to fix #12128 properly.
Wasmtime GitHub notifications bot (Dec 16 2025 at 22:04):dicej requested wasmtime-compiler-reviewers for a review on PR #12153.
Wasmtime GitHub notifications bot (Dec 16 2025 at 22:04):dicej requested cfallin for a review on PR #12153.
Wasmtime GitHub notifications bot (Dec 16 2025 at 22:04):dicej updated PR #12153.
Wasmtime GitHub notifications bot (Dec 16 2025 at 22:26):dicej updated PR #12153.
Wasmtime GitHub notifications bot (Dec 16 2025 at 22:39):dicej updated PR #12153.
Wasmtime GitHub notifications bot (Dec 17 2025 at 00:13):dicej updated PR #12153.
Wasmtime GitHub notifications bot (Dec 17 2025 at 00:24):dicej updated PR #12153.
Wasmtime GitHub notifications bot (Dec 22 2025 at 19:07):alexcrichton commented on PR #12153:
Current thinking, assuming I'm remembering this all correctly:
- Wasmtime will analyze/store a boolean that indicates, for a component, "components with core modules contain no components", aka core modules are located only in the leaves of a component composition. If this is
true, then reentrance checks in component<->component adapters can be skipped entirely. If this isfalse, which is expected to be quite rare today, then this PR's slow path will kick in.- The slow path is expected to be tweaked at the spec level. Right now flags a per-component-instance but they sort of need to be "find the least upper bound" in the path of components-to-the-root to set the reentrance flag on to ensure that implementation details of where implementations live aren't leaked (precise details TBD). This effectively means, however, that the
may_enterflag for the host-level component will be component-wide.- There will be a new check on the sync<->sync adapter which will manage
can_block-style flags. This is necessary to ensure that when a sync-typed function is called it's not allowed to block. This is an accidental omission and bug in today's implementation which will be fixed.In short, sync<->sync adapters will get faster on one axis (removing reentrance checks) but slower on another access (manipulating the
can_block) flag. Thecan_blockflag will live per-vm::ComponentInstanceand will be as fast as the current reentrance check. In essence the sync<->sync adapter performance profile is not expected to change.
Wasmtime GitHub notifications bot (Dec 22 2025 at 23:20):dicej updated PR #12153.
Wasmtime GitHub notifications bot (Dec 22 2025 at 23:23):dicej updated PR #12153.
Wasmtime GitHub notifications bot (Dec 22 2025 at 23:37):dicej updated PR #12153.
Wasmtime GitHub notifications bot (Dec 22 2025 at 23:50):dicej updated PR #12153.
Wasmtime GitHub notifications bot (Dec 23 2025 at 14:51):dicej updated PR #12153.
Wasmtime GitHub notifications bot (Dec 23 2025 at 21:46):dicej updated PR #12153.
Wasmtime GitHub notifications bot (Jan 06 2026 at 18:00):@alexcrichton Would you mind taking another look at this when you have time? I'm also happy to walk through it with you synchronously if that helps.
Wasmtime GitHub notifications bot (Jan 07 2026 at 17:53):dicej closed without merge PR #12153.
Wasmtime GitHub notifications bot (Jan 07 2026 at 17:53):After chatting with @alexcrichton about this, we decided to break this up into smaller PRs that address reentrance checks and may-block checks separately.
Last updated: Jan 10 2026 at 02:36 UTC