Hello,
I'm trying rust in webassembly.
I want to jail an arbitrary part of the memory at runtime which has not been used by the memory allocator.
For example, 65000 to 65200 must never be overwritten by rust (ie a kind of read only memory area).
Maybe by declaring a slice, but I am not sure if it is the best way to achieve this goal.
Thank you in advance for your help.
If you're looking to share some memory chunk between JavaScript and Rust, it's possible to use #[no_mangle] on some statically allocated array, which will export the array chunk and then you can use it from JavaScript. For example this is how these web assembly demos work: Web Demos - Cliffle.
This is quite a challenge… When Rust allocates, it can request the memory to grow which will invalidate all references from outside.
What are you trying to build? There is probably a better solution.
Why not use a Vec<u8>? That gives you a grow able array of bytes to work with.
Yes, and probably impossible to achieve without the multi memory feature of webassembly.
While I agree with other commentors saying that you probably want something else, with enough effort, this should be possible.
There's now way to tell the default allocator to reserve a particualr section of memory, but if you were to write your own custom allocator, you could definitely include that functionality!
You could take an existing custom allocator, like wee_alloc, fork it, and modify it to never allocate to the area of memory you want to preserve. Then with #[global_allocator] annotation, all allocations would go through your allocator, and nothing would ever write to that region of memory.
If you limited your total allocations, yes it can be done. But you have to request all the memory upfront and can't request any more once the segment is exposed.
Not something that is likely to work for most code.
Why would limiting allocations be required?
I would think that if modifying the allocator, it should be fairly easy to request a big enough memory region to include the blocked off addresses up front, and then just mark those regions as "allocated". If this is done on the first memalloc, then I would expect it to be entirely possibly to continue to make any number of new allocations with no limit. What would cause us to need to limit that?
From reading the spec, growing the linear memory detaches the underlying memory from the arraybuffer. So any references from outside are invalidated. If that isn't a problem then it would be possible.
True! I was assuming whatever was writing to the given memory region would do what most wasm programs do today and refresh their references when more memory is requested.
If there's something already handling that (like stdweb or wasm-bindgen), or if a memory reference is re-retrieved each time the outer javascript writes to WASM memory, then it should indeed be possible.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.