Allow to access a Memory with more than 32767 pages
#166
Conversation
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
kpreisser
changed the title
Memory with more than 32767 pages
peterhuene
reviewed
Oct 20, 2022
Member
peterhuene
left a comment
peterhuene
left a comment
There was a problem hiding this comment.
Thanks for this fix too!
Just a few minor nits and a more general comment regarding all the new long overloads for the memory accessor methods.
kpreisser
force-pushed
the
largeMemoryAccess
branch
from
12330ce to
35359f4
Compare
kpreisser
force-pushed
the
largeMemoryAccess
branch
from
9e71be3 to
c57a79f
Compare
peterhuene
approved these changes
Oct 21, 2022
Member
|
@kpreisser thanks for addressing this! |
kpreisser
added a commit
to kpreisser/wasmtime-dotnet
that referenced
this pull request
Oct 22, 2022
…e Wasmtime C API with bytecodealliance/wasmtime#3182. Additionally, add tests to verify the new APIs added with bytecodealliance#166 are able to access a memory beyond the 4 GiB area.
peterhuene
pushed a commit
that referenced
this pull request
Oct 31, 2022
* Add support for enabling the Memory64 proposal, which was added to the Wasmtime C API with bytecodealliance/wasmtime#3182. Additionally, add tests to verify the new APIs added with #166 are able to access a memory beyond the 4 GiB area. * Follow-Up: Adjust the API to match the new C API introduced with bytecodealliance/wasmtime#3153, in order to support 64-bit memory. This also fixes the definition of native functions wasmtime_memory_size and wasmtime_memory_grow, which previously incorrectly used a UInt32 instead of UInt64, and config functions taking a bool parameter, which were previously missing the MarshalAsAttribute (to marshal a Boolean as 1 byte instead of 4 bytes). * Follow-Up: Validate the arguments. * Simplify. * Simplify.
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.
Hi, this PR adds new
Int64-based APIs toMemoryto allow to access memories with more than 32767 pages.Fixes #165
I added a new method
GetSpan(long address, int length)as well asGetSpan<T>(long address, int length)to retrieve aSpan<byte>andSpan<T>starting at the givenInt64address. Additionally, I added aGetLength()andGetPointer()methods for getting a raw pointer to the memory, and the memory length in bytes (in case you want to access the whole memory area at once, even if it exceeds a size of 2 GiB).Additionally, for the
ReadXyz()/WriteXyz()methods, I added new overloads taking anInt64address,and fixed the existing (. The old (Int32-based) methods to not throw anOverflowExceptionInt32-based) APIs have been removed as breaking change.I also added an
ObsoleteAttributeto theGetSpan()method to indicate that it will throw anOverflowExceptionwhen the memory has more than 32767 pages, with a recommendation to use theGetSpan(long address, int length)method instead.What do you think?
Thanks!