WASM-Speichermodell und -verwaltung
Verstehen Sie das lineare Speichermodell von WebAssembly sowie die Zuweisung, den Zugriff und die Verwaltung von Speicher in WASM-Modulen.
WASM-Speichermodell und -verwaltung ist eine kostenlose WebAssembly (WASM) for High Performance Apps-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des WebAssembly (WASM) for High Performance Apps-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der WebAssembly (WASM) for High Performance Apps-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
WASM Linear Memory: The Basics
WebAssembly uses a linear memory model. Think of it as a single, large, contiguous array of bytes, similar to how traditional programs manage memory.
- This memory is separate from JavaScript's memory.
- It's accessed by WASM modules as a flat address space, starting from address 0.
- All data (integers, floats, strings, arrays) lives within this single memory block.
The `WebAssembly.Memory` Object
In JavaScript, WASM memory is represented by the WebAssembly.Memory object. This object holds the actual memory buffer.
You can create it:
- When instantiating a WASM module, it can declare and create its own memory.
- You can also pass an existing
WebAssembly.Memoryinstance from JavaScript to the module.
const memory = new WebAssembly.Memory({
initial: 1, // Start with 1 page (64KB)
maximum: 10 // Max allowed 10 pages
});
// This 'memory' object is then passed to the
// WASM module during instantiation.Memory Pages: The Unit of Size
WASM memory is organized into fixed-size units called pages. Each page is exactly 64 KiB (65,536 bytes) in size.
- The
initialandmaximumproperties ofWebAssembly.Memoryare always defined in terms of pages. - A WASM module might start with just 1 page, growing its memory as needed for efficiency.
- This page-based system allows for efficient memory management and protection.
JavaScript's View into Memory
JavaScript cannot directly access WASM's linear memory using raw pointers. Instead, it gets an ArrayBuffer view of the memory.
You then use TypedArrays (like Uint8Array, Int32Array, Float64Array) or a DataView to read and write specific data types at specific offsets within that ArrayBuffer.
const memoryBuffer = instance.exports.memory.buffer;
const uint8Array = new Uint8Array(memoryBuffer); // Byte-level view
const int32Array = new Int32Array(memoryBuffer); // 4-byte integer viewAllocating Memory in C/WASM
When you compile C/C++ to WASM, functions like malloc allocate memory from WASM's linear memory. This example shows a C function that allocates space for an integer array.
It returns a memory offset (an integer) rather than a direct pointer, which JavaScript then uses.
#include <stdlib.h>
#ifdef __EMSCRIPTEN__
#include <emscripten.h>
#else
#define EMSCRIPTEN_KEEPALIVE
#endif
EMSCRIPTEN_KEEPALIVE
int* allocate_int_array(int size) {
int* arr = (int*) malloc(size * sizeof(int));
if (arr) {
for (int i = 0; i < size; ++i) {
arr[i] = i * 10; // Initialize with some data
}
}
return arr; // Returns memory offset
}
int main() {
// Main function is often a placeholder for WASM modules
return 0;
}Accessing C-Allocated Memory from JS
After WASM allocates memory (e.g., using allocate_int_array), JavaScript can access it using the returned offset and a TypedArray.
The offset tells JS exactly where in the underlying ArrayBuffer the allocated data begins, allowing precise read/write operations.
// Assuming 'instance' is your WASM module instance
const offset = instance.exports.allocate_int_array(5);
const memoryBuffer = instance.exports.memory.buffer;
// Create an Int32Array view starting at the offset
const intArray = new Int32Array(memoryBuffer, offset, 5);
console.log(intArray[0]); // Expected: 0
console.log(intArray[1]); // Expected: 10
// ... and so onDeallocating Memory with `free`
Just like in C, it's crucial to deallocate memory you've allocated using malloc to prevent memory leaks. The free function in WASM works similarly, releasing the memory back to the WASM runtime.
This C function frees a previously allocated memory block using its offset.
#include <stdlib.h>
#ifdef __EMSCRIPTEN__
#include <emscripten.h>
#else
#define EMSCRIPTEN_KEEPALIVE
#endif
EMSCRIPTEN_KEEPALIVE
void free_wasm_memory(int* ptr) {
if (ptr) {
free(ptr); // Release the memory block
}
}
int main() {
return 0;
}Dynamically Growing Memory
WASM memory isn't fixed; it can grow! The memory.grow(numPages) method, exposed on the WebAssembly.Memory object, allows you to increase the memory size by a specified number of pages.
- This method returns the previous number of pages.
- If
growfails (e.g., exceeds themaximum), it returns -1. - Important: Existing TypedArray views become invalid after a grow operation; you must create new ones from the updated
memory.buffer.
const currentPages = instance.exports.memory.grow(1); // Add 1 page
console.log(`Memory grew from ${currentPages} pages.`);
// After growing, always recreate TypedArray views!
const newMemoryBuffer = instance.exports.memory.buffer;
const newUint8Array = new Uint8Array(newMemoryBuffer);Memory Management Check
Which of the following statements about WebAssembly's linear memory model are TRUE?
Recap: WASM Memory Management
We've explored WebAssembly's linear memory model, a foundational concept for high-performance applications.
- WASM memory is a contiguous byte array, separate from JS memory.
- It's managed by the
WebAssembly.Memoryobject and organized into 64 KiB pages. - JavaScript interacts with this memory using
ArrayBufferandTypedArraysto read and write data. - C functions like
mallocandfreeoperate within this WASM memory space, with `malloc` returning an offset. - Memory can be dynamically increased using
memory.grow(), but requires re-creating JS views.
Understanding these concepts is key to efficient data exchange and memory handling in WASM applications.
Häufig gestellte Fragen
Ist die Lektion „WASM-Speichermodell und -verwaltung“ kostenlos?
Ja — der vollständige Text von „WASM-Speichermodell und -verwaltung“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des WebAssembly (WASM) for High Performance Apps-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der WebAssembly (WASM) for High Performance Apps-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „WASM-Speichermodell und -verwaltung“?
Verstehen Sie das lineare Speichermodell von WebAssembly sowie die Zuweisung, den Zugriff und die Verwaltung von Speicher in WASM-Modulen. Du übst WebAssembly (WASM) for High Performance Apps mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um WebAssembly (WASM) for High Performance Apps zu starten?
Keine Vorkenntnisse erforderlich. WebAssembly (WASM) for High Performance Apps auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.
Wie lange dauert die Lektion „WASM-Speichermodell und -verwaltung“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser WebAssembly (WASM) for High Performance Apps-Lektion Code schreiben und ausführen?
Ja. Jede WebAssembly (WASM) for High Performance Apps-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Komplexe Datenstrukturen übergeben
- WASM-Speichermodell und -verwaltung
- Gemeinsamer Speicher und Atomics
- Linearen Speicher erweitern und verwalten