A host-created WebAssembly.Memory holds six original float32 values at byte 1024. Grow the actual nonshared memory and inspect the old buffer length and reconstructed current view; GPU upload remains a separate task.
Describe an owned region, not just a number
The interactive probe creates nonshared WebAssembly.Memory from JavaScript with one initial page and a maximum of two. It writes the original values at byte offset 1024. For a compiled-module integration, require a module descriptor that establishes ownership and a region lifetime; the host probe does not supply that proof.
Store three two-component float32 vertices in order:
| Vertex | x | y | Component offsets from region start |
|---|---|---|---|
| A | -0.5 | -0.5 | 0, 4 |
| B | 0.5 | -0.5 | 8, 12 |
| C | 0 | 0.5 | 16, 20 |
There are six elements, four bytes per element, and 24 bytes total. The region occupies the half-open byte interval [1024, 1048). Its final component starts at 1044 and occupies four bytes.
The descriptor needs the module generation, memory identity, region ownership/lifetime, pointer in bytes, element type, and element count. A hard-coded address copied from another module is not evidence of ownership. These descriptor values are the authored contract; the actual module exports and bytes must later establish it.
The initial memory capacity target is 65,536 bytes. The region's endpoint 1048 fits within that capacity. Do not pass 24 as a float element count: that would describe a 96-byte view rather than these six components.
Check alignment, capacity, and byte interpretation
Before constructing a direct float32 view, validate that pointer and count are nonnegative integers, arithmetic stays within the supported address range, the pointer is four-byte aligned, and the complete region fits in the current buffer. Also confirm that the descriptor belongs to the current module and that its lifetime is active.
Use two held cases to expose different failures:
| pointer | Requested length | Initial capacity | Disposition |
|---|---|---|---|
| 1026 | 24 bytes | 65,536 bytes | Hold: not four-byte aligned |
| 65,520 | 24 bytes | 65,536 bytes | Hold: endpoint 65,544 exceeds capacity |
Neither case should be uploaded by truncating the data, rounding the pointer, or supplying zeros. A numerical bounds check alone also cannot establish that a region is owned by the module.
The MDN WebAssembly Memory reference specifies little-endian memory. Decode the six values with an explicitly little-endian byte-reading check, then confirm that the typed-array path represents those same values on the actual host. If that representation does not match, use an explicitly decoded upload array rather than silently reinterpreting bytes.
The expected flattened values are -0.5, -0.5, 0.5, -0.5, 0, 0.5. This is an acceptance target, not a report that a Wasm data segment or compiler output has been inspected.
Refresh the view after successful growth
Capture the initial buffer identity for the ledger. Then call memory.grow(1) once for this nonshared fixture.
According to MDN's grow reference, pages are 64 KiB and the returned size is the previous page count. For this case, the expected return is 1 and the new capacity is 131,072 bytes. The old nonshared buffer becomes detached; obtain the current buffer again after growth.
The expected comparison is:
| Item | Before growth | After successful growth |
|---|---|---|
| Current capacity | 65,536 bytes | 131,072 bytes |
| Previously captured buffer | Current buffer | Detached; byteLength 0 |
| Owned region pointer | 1024 | 1024 under this static-region contract |
| Required upload view | Initial current view | Newly constructed current view |
Recheck the descriptor and current bounds, rebuild the view at byte offset 1024 with six float32 elements, and decode the known values again. Do not upload from the cached old view.
Buffer replacement does not, by itself, mean that the region was freed or its pointer relocated. The pointer remains valid in this host fixture because the probe keeps the initialized region alive. This does not establish lifetime for arbitrary malloc allocations or a different module generation.
Try the worked example
Inspect the default region, then Grow 1 page. The old nonshared buffer becomes 0 bytes, while a current view still reads the six values. Reset and enter 1026 to see the alignment hold; 65520 fails the original capacity bound. A current buffer check does not prove arbitrary module ownership.
This executes the WebAssembly.Memory API on a host-created fixture. It does not compile a Wasm module, establish its region lifetime, upload a GPU buffer, or render a triangle.
Recreate this example
Build one complete self-contained HTML page for this task: execute a real nonshared WebAssembly.Memory growth and inspect current float32 view bounds.
Use these exact original practice data and worked expectations: Start with one page and a maximum of two; each page is 65,536 bytes. Use byte pointer 1024 and six float32 elements: 24 bytes ending at 1048. Values: -0.5, -0.5, 0.5, -0.5, 0, 0.5. Growing by one page returns 1, expands current memory to 131,072 bytes, and detaches the old buffer (0 bytes). Hold misaligned pointer 1026 and the initial out-of-bounds request 65520 + 24.
Implement the following useful local interactions: Pointer input, Inspect, Grow 1 page, and Reset. Create memory from JavaScript and initialize six little-endian floats; explicitly distinguish this host fixture from a compiled module-owned region. Perform actual growth, old-buffer detachment, current-view reconstruction, alignment checks, and bounds checks. No WebGL rendering. Preserve the supplied source text and distinguish an uncomputed state, a successful local result, and an invalid or incomplete input. Update output only from the current input snapshot. An input edit must retire stale feedback until the reader runs the relevant action again. Do not silently invent missing values or replace a failing case with a success.
Design the page as a compact source-and-result developer workbench with readable code, labeled inputs, and a separate explanation area. Put a compact task heading, actual sample data, the main result, and usable controls early enough to be useful on a narrow screen. Use readable text of at least 16px, generous paragraph spacing, strong contrast, native labels, accessible buttons, and visible keyboard focus. Stack long records at 360px and wrap code without page-level horizontal overflow.
Use type=button and explicit querySelector-based click handlers rather than relying on form submission. If Enter is useful, handle it only on the relevant input and ignore isComposing. Keep effects within this open page; no remote dependencies, network calls, persistence, fake downloads, or automated sending. This executes the WebAssembly.Memory API on a host-created fixture. It does not compile a Wasm module, establish its region lifetime, upload a GPU buffer, or render a triangle. Place worked explanations beside their data and identify teacher or synthetic examples clearly. Output only the complete HTML document, with inline styles and script and LF line endings.
Review the live WebAssembly memory-view probe in NOS
Bind an actual module’s pointer, count, ownership, and generation before adding the GPU upload. Use the memory-contract explanation in NOS to review the 24-byte region and rebuilt view together, then revise eligible static integration notes in visual editing mode before wiring the module to the upload.