js-polyfill: support Safari, which doesn't have instantiateStreaming#136
Merged
sunfishcode merged 1 commit intobytecodealliance:masterfrom May 10, 2019
Merged
Conversation
Member
|
Thanks! |
mooori
pushed a commit
to mooori/wasmtime
that referenced
this pull request
Dec 20, 2023
Tweak worst case size
frank-emrich
added a commit
to frank-emrich/wasmtime
that referenced
this pull request
Mar 21, 2024
…ns (bytecodealliance#136) Currently, we can overflow the stack while running inside a continuation, without the runtime having any way of detecting this. This PR partially rectifies this, by making the existing stack limit checks that get emitted by cranelift in every wasm function prelude work correctly while running inside a continuation. All that was required to enable the stack limit checks was the following: 1. Stop zero-ing out the `stack_limit` value in `VMRuntimeLimits` whenever we `resume` a continuation. 2. When creating a continuation, set a reasonable value for the `stack_limits` value in its `StackLimits` object. Note that all the required infrastructure to make sure that whenever we switch stacks, we save and restore the `stack_limits` value inside `VMRuntimeLimits` and the `StackLimits` object of the involved stacks was already implemented in bytecodealliance#98 and bytecodealliance#99. In this sense, enabling these checks is "free": The limits were already checked, but previously using a limit of 0. The only remaining question is what the "reasonable value" for the stack limits value mentioned above is. As discussed in bytecodealliance#122, the stack limit checks that cranelift emits in function preludes are rather limited, and these limitations are reflected in the checks that this PR provides: When entering a wasm function, they check that the current stack pointer is larger than the `stack_limit` value in `VMRuntimeLimits`. They do not take into account how much stack space the function itself will occupy. No stack limit checks are performed when calling a host function. Thus, this PR defines a config option `wasmfx_red_zone_size`. The idea is that we define the stack limit as `bottom_of_fiber_stack` + `wasmfx_red_zone_size`. Thus, the stack checks boil down to the following: Whenever we enter a wasm function while inside a continuation, we ensure that there are at least `wasmfx_red_zone_size` bytes of stack space left. I've set the default value for `wasmfx_red_zone_size` to 32k. To get a rough idea for a sensible value, I determined that a call to the `fd_write` WASI function occupies ~21k of stack space, and generously rounded this up to 32k. **Important**: This means that these stack limit checks are incomplete: Calling a wasm or host function that occupies more than `wasmfx_red_zone_size` of stack space may still result in an undetected stack overflow!
avanhatt
pushed a commit
to wellesley-prog-sys/wasmtime
that referenced
this pull request
Oct 18, 2024
Updates the `int2bv` operator so its width can be an expression. The current behavior was problematic in bytecodealliance#135, where it prevents the use of `int2bv` in a macro expansion. This PR brings `int2bv` in line with other operators taking an integer width, such as zero extension.
dicej
pushed a commit
to dicej/wasmtime
that referenced
this pull request
May 8, 2025
…sync Enable component-model-async in release artifacts
alexcrichton
pushed a commit
to alexcrichton/wasmtime
that referenced
this pull request
Oct 8, 2025
* chore(deps): update wasmtime & upstream deps This commit updates wasmtime along with other deps: - wasmtime: v31 -> v36.0.2 - wasmparser et al: *.228 -> *.238 * fix(deps): use major version of wasmtime in dep Co-authored-by: Till Schneidereit <till@tillschneidereit.net> --------- Co-authored-by: Till Schneidereit <till@tillschneidereit.net>
bongjunj
pushed a commit
to prosyslab/wasmtime
that referenced
this pull request
Oct 20, 2025
* chore(deps): update wasmtime & upstream deps This commit updates wasmtime along with other deps: - wasmtime: v31 -> v36.0.2 - wasmparser et al: *.228 -> *.238 * fix(deps): use major version of wasmtime in dep Co-authored-by: Till Schneidereit <till@tillschneidereit.net> --------- Co-authored-by: Till Schneidereit <till@tillschneidereit.net>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes #134.