-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: mappable memories #4
Comments
Thanks for posting this, and apologies for the delay in replying. To make sure I understand,
How are pre-map pages provided? Is the Max page count accounting for mapped pages across different mappable memories?
I guess the safest way to do this would be to expose slices of Wasm memory to be different JSArrayBuffers, though this means that the JSArrayBuffers and Wasm memories would need to be decoupled more than they are right now. That way, it should be straightforward to detach any ArrayBuffers that are backed by memory that has been unmapped.
|
I could imagine a system similar to what's currently done for linear memory. I had not at the time of writing that up (and still don't) had a concrete answer for that question - I was trying to explain the structure at a high level to draw snd gauge interest with my initial comment, not offer a complete competing proposal.
The limit would be per-memory. A global max could be added, but shouldn't be required.
To be clear, I said "could" not "should", and there may be better ways of doing it. |
Technically AArch64 has supported 52 bits for a while now, as provided by the |
Is that all user-addressable? Or is it only kernel-addressable like in x86? Edit: Also, x86 has that 2^48 user-mode limit also. |
Yes, it is. Here is how it works on Linux, for instance. |
@akirilov-arm Seems only for some devices, given it's explicity optional. Makes this feel unportable. Also, 2^48 bytes = 256 TiB. Something worth keeping in context - it's not a small number. And worst case scenario, if that does prove too low of a limit, it'd be easy enough to extend to fill out the 64-bit space fully. (I doubt this will happen anytime soon, but history has had a knack for laughing at us people daring to make such predictions.) |
Yes, it is an optional feature. However, I am not sure that I understand the portability concerns, given that a similar situation exists even in the Wasm MVP - there is no guarantee that the Wasm runtime would be able to provide the whole 4 GiB memory range that is covered by a 32-bit index. Anyway, my point is not to argue whether 48-bit memory spaces are big enough or not, but merely to point out that one of the assumptions in your suggestion is not entirely correct. |
Here's the idea: instead of doing everything dynamically or just everything statically, it could be done somewhere in the middle via a special type of memory called a mappable memory. This is very close to what OSs actually offer, while still being very easily checked and secured.
start:i32
+count:i32
ranges operating at page resolution.memory.protect
andmemory.discard
can do as they need.memory.protect
masks to further accelerate loading.The text was updated successfully, but these errors were encountered: