[draft] show how Arc<Mmap> would work #9687
Draft
+488
−237
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
In upcoming work we're going to centralize memory management inside `Mmap`. In order to do that, we need memory that logically borrows from the `Mmap` to have access to it. That turns out to be possible in some situations but very difficult in others (see bytecodealliance#9681 for an attempt that was a real hassle to get working). To prepare for this work, start moving these uses to be behind `Arc`. These aren't cloned at the moment, but they will be in the future.
Return a single `SendSyncPtr` -- the platform-independent context converts to the various raw pointer types as desired. This simplifies upcoming work where I wanted to return a `SendSyncPtr`.
This is part of the work to centralize memory management into the `mmap` module. This commit introduces a few structures which aid in that process, and starts converting one of the functions (`MemoryImageSource::map_at`) into this module. The structures introduced are: * `MemoryBase`: `RuntimeLinearMemory::base_ptr` is now `RuntimeLinearMemory::base`, which returns a `MemoryBase`. This is either a raw pointer or an mmap + an offset into it. * `MmapOffset`: A combination of a reference to an mmap and an offset into it. Logically represents a pointer into a mapped section of memory. * `MmapOffsetRaw`: Some components like `MemoryImageSlot` logically work on borrowed memory, but adding lifetime parameters to them would introduce self-reference issues. Instead, store a raw form of the `MmapOffset` such that it can be reconstructed at runtime. This should work for most future work here, but not all of it -- I've written out some comments along with ideas.
sunshowers
commented
Nov 26, 2024
Comment on lines
+540
to
+546
| // Note that this code would be incorrect if clear-on-drop | ||
| // were enabled. That's because in the struct definition, | ||
| // `memory_image` above is listed after `alloc`. Rust drops | ||
| // fields in the order they're defined, so `memory_image` | ||
| // would be dropped after `alloc`. If clear-on-drop were | ||
| // enabled, `memory_image` would end up remapping a bunch of | ||
| // memory after it was unmapped by the `alloc` drop. |
There was a problem hiding this comment.
This was a subtle dependency that took me a bit to understand.
There was a problem hiding this comment.
(And this is only dangerous when alloc represents an owned memory allocation. It's fine if alloc is borrowed. This is a subtle point.)
github-actions
bot
added
the
wasmtime:api
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in 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.
Draft to show how #9682 would work. (Will clean this up before putting up.)