More refactoring to remove MemoryStyle
#9543
Merged
Conversation
This file contains 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
alexcrichton
requested review from
abrown and
pchickey
and removed request for
a team
github-actions
bot
added
the
wasmtime:api
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Nov 2, 2024
This commit removes the terminology of "static" and "dynamic" memories from the public-facing documentation of Wasmtime, notably on the `Config` structure and its various configuration settings. The goal of this commit is in the same vein as bytecodealliance#9543 which is to simplify the memory settings of Wasmtime for users in this case. This change doesn't actually have any code changes beyond renames (and handling now-deprecated CLI options). The goal of this commit is to basically rewrite how we document the effect of various settings of Wasmtime. Notably: * `Config::static_memory_maximum_size` is now `memory_reservation`. * `Config::static_memory_forced` is now `memory_reservation_is_maximum`. * `Config::dynamic_memory_reserved_for_growth` is now `memory_reservation_for_growth`. Documentation for all of these options has been rewritten and updated to take into account the removal of "dynamic" and "static" terminology. Additionally more words have been written about the various effects of each setting and how things related to wasm features such as index type sizes and custom page sizes. The rewritten documentation is intended to basically already match what Wasmtime does today. I believe that all of these settings are useful in one form or another so none have been dropped but the updated documentation is intended to help simplify the mental model for how they're processed internally and how they affect allocations and such.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Nov 4, 2024
This commit removes the terminology of "static" and "dynamic" memories from the public-facing documentation of Wasmtime, notably on the `Config` structure and its various configuration settings. The goal of this commit is in the same vein as bytecodealliance#9543 which is to simplify the memory settings of Wasmtime for users in this case. This change doesn't actually have any code changes beyond renames (and handling now-deprecated CLI options). The goal of this commit is to basically rewrite how we document the effect of various settings of Wasmtime. Notably: * `Config::static_memory_maximum_size` is now `memory_reservation`. * `Config::static_memory_forced` is now `memory_reservation_is_maximum`. * `Config::dynamic_memory_reserved_for_growth` is now `memory_reservation_for_growth`. Documentation for all of these options has been rewritten and updated to take into account the removal of "dynamic" and "static" terminology. Additionally more words have been written about the various effects of each setting and how things related to wasm features such as index type sizes and custom page sizes. The rewritten documentation is intended to basically already match what Wasmtime does today. I believe that all of these settings are useful in one form or another so none have been dropped but the updated documentation is intended to help simplify the mental model for how they're processed internally and how they affect allocations and such.
abrown
reviewed
Nov 4, 2024
| offset: Offset32::new(current_length_offset), | ||
| global_type: pointer_type, | ||
| flags: MemFlags::trusted(), | ||
| }); |
There was a problem hiding this comment.
It's this extra global that is causing the changes in the disassembly tests, right? E.g., gv5?
There was a problem hiding this comment.
It would appear that gv4 is not being used in those tests, so we're adding an unused global here and I'm debating the pros and cons of that.
There was a problem hiding this comment.
Right yeah this is the global being added. I wrote up a bit above about this but it's essentially easier given the current code shape to assume that the global value is always there rather than calculate if it'll be needed in a function body and create it and/or lazily creating it on-demand. My hope is that the "overhead" here is just a few bytes in a vector per-function which in theory doesn't have too much impact, but I'll admit I haven't measured.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Nov 4, 2024
This commit removes the terminology of "static" and "dynamic" memories from the public-facing documentation of Wasmtime, notably on the `Config` structure and its various configuration settings. The goal of this commit is in the same vein as bytecodealliance#9543 which is to simplify the memory settings of Wasmtime for users in this case. This change doesn't actually have any code changes beyond renames (and handling now-deprecated CLI options). The goal of this commit is to basically rewrite how we document the effect of various settings of Wasmtime. Notably: * `Config::static_memory_maximum_size` is now `memory_reservation`. * `Config::static_memory_forced` is now `memory_reservation_is_maximum`. * `Config::dynamic_memory_reserved_for_growth` is now `memory_reservation_for_growth`. Documentation for all of these options has been rewritten and updated to take into account the removal of "dynamic" and "static" terminology. Additionally more words have been written about the various effects of each setting and how things related to wasm features such as index type sizes and custom page sizes. The rewritten documentation is intended to basically already match what Wasmtime does today. I believe that all of these settings are useful in one form or another so none have been dropped but the updated documentation is intended to help simplify the mental model for how they're processed internally and how they affect allocations and such.
abrown
approved these changes
Nov 5, 2024
github-merge-queue bot
pushed a commit
that referenced
this pull request
Nov 5, 2024
* Remove static/dynamic memories from public docs This commit removes the terminology of "static" and "dynamic" memories from the public-facing documentation of Wasmtime, notably on the `Config` structure and its various configuration settings. The goal of this commit is in the same vein as #9543 which is to simplify the memory settings of Wasmtime for users in this case. This change doesn't actually have any code changes beyond renames (and handling now-deprecated CLI options). The goal of this commit is to basically rewrite how we document the effect of various settings of Wasmtime. Notably: * `Config::static_memory_maximum_size` is now `memory_reservation`. * `Config::static_memory_forced` is now `memory_reservation_is_maximum`. * `Config::dynamic_memory_reserved_for_growth` is now `memory_reservation_for_growth`. Documentation for all of these options has been rewritten and updated to take into account the removal of "dynamic" and "static" terminology. Additionally more words have been written about the various effects of each setting and how things related to wasm features such as index type sizes and custom page sizes. The rewritten documentation is intended to basically already match what Wasmtime does today. I believe that all of these settings are useful in one form or another so none have been dropped but the updated documentation is intended to help simplify the mental model for how they're processed internally and how they affect allocations and such. * Fix how the setting is flipped * Review comments
The second option is always `tunables.memory_guard_size`, so propagate this to the various locations reading it.
Push reading `Tunables` down further into where it's needed instead of having duplicate storage per-heap.
This commit plumbs `wasmtime_environ::Memory` further down the stack in Winch to where heaps are processed. This avoids an extra layer of indirection through a `Heap` type which peels apart a `Memory` to pick out a few fields. In the future this'll be used with more helpers on `Memory` to simplify the static/dynamic memory cases.
This commit removes the `HeapStyle` structure from Cranelift and instead plumbs the `wasmtime_environ::Memory` type further down the stack through in `HeapData` (same as Winch before this commit). This removes redundant fields in `MemoryType` and continues to push down the `MemoryStyle` structure even further. This commit additionally and unconditionally defines a `GlobalValue` for the heap limit of memory. This is unused most of the time for 32-bit wasm and is conditionally used depending on how bounds checks are generated. This is a small amount of bloat to each function since previously functions that didn't need this `GlobalValue` elided it. A future refactoring, however, will make it a bit more clear how this is used even for "static" memories.
alexcrichton
force-pushed
the
push-memory-type-down-in-compilers
branch
from
ac86a68 to
3f34ac0
Compare
|
@fitzgen mind giving a once-over confirmation here as well? |
ncaq
added a commit
to ncaq/wasmtime-hs
that referenced
this pull request
Feb 10, 2025
With the following PR, the concept of static/dynamic has disappeared from wasmtime. [More refactoring to remove `MemoryStyle` by alexcrichton · Pull Request #9543 · bytecodealliance/wasmtime](bytecodealliance/wasmtime#9543)
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
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 commit has more refactoring to simplify handling of linear memories in Wasmtime. The end goal is to remove the static/dynamic distinction and simplify the internal implementation and external interface. This is along the same lines of #9528, #9532, #9531, and #9530. The goal of this PR is a series of standalone commits which work towards futher "pushing down" the usage of
MemoryStyledown to the consumers of bounds check code. The goal here is to remove layers of abstraction and instead unify everything around the same abstraction ofTunablesandwasmtime_environ::Memory. Many fields in Winch/CraneliftHeapDatahave been removed in favor of storingMemorydirectly.This PR affects generated golden tests because previously the global value for the heap bound was not generated if the heap was a "static" heap. With the eventual removal of static/dynamic distinction it's easier to just always generate this and have it not get used most of the time. Thus while the clif output tests are changing none of the actual generated code itself should be changing.