Memory Management in WebAssembly with Rust

Reading Time: 4 minutes

Hello, folks! your wait is over, we have come up with a new blog on WebAssembly with Rust. In this blog, we will discuss about the memory management in web Assembly applications with Rust. Hope you will enjoy the blog.

The WebAssembly can follow the Linear Memory Model to internally manage the memory in the application. So let’s start the discussion from what Linear Memory model is?

Linear Memory Model:

A linear memory model, also known as the flat memory model refers to a memory addressing technique in which memory is organised in a single contiguous address space. This means that the processing unit can access these memory locations directly as well as linearly.

To better understand a linear memory model, we should understand two basic components: address and data. Address is a hexadecimal number which is used to denote the exact place of a memory chunk. Data is the value stored in that memory. In a linear memory model, the entire memory space is linear, sequential, and contiguous.
The address ranges from 0 to MaxByte -1, where MaxBytes is the maximum limit of memory. Each program uses one 32-bit linear memory space, that means 2^32 = 4 GB of memory can be addressed using this memory model. The operating system then translates these linear addresses to physical addresses using paging schemes. More…

Advantages of Linear Memory model:

• Contiguous allocation of memory.
• No Internal fragmentation.
• Maximum execution speed.

Disadvantages of Linear Memory model:

• High execution time for rearranging elements.
• Wastes a lot of memory area.

Memory Management:

Linear Memory is another important WebAssembly building block that is typically used to represent the entire heap of a compiled C/C++ application. From a JavaScript perspective, linear memory (henceforth, just “memory”) can be thought of as a resizable Array Buffer that is carefully optimised for low-overhead sand boxing of loads and stores.
Memories can be created from JavaScript by supplying their initial size and, optionally, their maximum size:

var memory = new WebAssembly.Memory({initial:10, maximum:100});

The first important thing to notice is that the unit of initial and maximum is WebAssembly pages which are fixed to be 64KiB. Thus, memory above has an initial size of 10 pages, or 640KiB, and a maximum size of 6.4MiB.
Since most byte-range operations in JavaScript already operate on ArrayBuffer and typed arrays, rather than defining a whole new set of incompatible operations, WebAssembly.Memory exposes its bytes by simply providing a buffer getter that returns an ArrayBuffer. For example, to write 58 directly into the first word of linear memory:

new Uint32Array(memory.buffer)[0] = 58;

Once created, a memory can be grown by calls to Memory.prototype.grow, where again the argument is specified in units of WebAssembly pages:

memory.grow(1);

If a maximum is supplied upon creation, attempts to grow past this maximum will throw a RangeError exception. The engines take advantage of this supplied upper-bounds to reserve memory ahead of time which can make resizing more efficient.

Memory Leaks:

When you manage your own memory you may forget to clear it out. This can cause the system to run out of memory.

If a WebAssembly module instance had direct access to memory, and if it forgot to clear out that memory before it went out of scope, then the browser could leak memory. But because the memory object is just a JavaScript object, it itself is tracked by the garbage collector (even though its contents are not).
The whole memory array can just be garbage collected, When the WebAssembly instance that the memory object is attached to goes out of scope

Memory Isolation:

When people hear that WebAssembly gives you direct access to memory, it can make them a little nervous. They think that a malicious WebAssembly module could go in and dig around in memory it shouldn’t be able to. But that isn’t the case.

The bounds of the ArrayBuffer provide a boundary. It’s a limit to what memory the WebAssembly module can touch directly.

It can directly touch the bytes that are inside of this array but it can’t see anything that’s outside the bounds of this array.

For example, any other JS objects that are in memory, like the window global, aren’t accessible to WebAssembly. That’s really important for security.

Note: I hope our blogs help you to enhance your learning. I’ll post more blogs on WebAssembly with Rust. Stay Tuned.

If you want to read more content like this?  Subscribe Rust Times Newsletter and receive insights and latest updates, bi-weekly, straight into your inbox. Subscribe Rust Times Newsletter: https://bit.ly/2Vdlld7 .

Video: Learn more and enhance your knowledge and skills of Rust Language by subscribing Rust Times newsletter and receive updates bi-weekly. https://bit.ly/2Vdlld7 .

Template: For more such template updates, subscribe Rust Times Newsletter: https://bit.ly/2Vdlld7

Happy learning!!!

References: