How does using malloc, then memory growth work?

[Michael Hagar]

It's mentioned in the docs here: https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html?highlight=memory_growth#access-memory-from-javascript

That if using the ALLOW_MEMORY_GROWTH option, the JS side needs to refresh the views on the memory buffer.

If I used Module._malloc, and then memory grows, are the values returned from the original Module._malloc call still valid? If the values returned refer to specific positions in the underlying buffer, it seems like they would be invalidated, but that doesn't seem to be the case (they still seem valid).

What's going on here? I have a feeling I'm misunderstanding how Emscripten works with C++ memory.

[Sam Clegg]

When the memory grows it doesn't affect previously malloc'd memory and all old pointers are still valid.

The memory views used by JS (HEAP8, HEAP32, etc) are automatically updated via calling `updateMemoryViews` from the `growMemory` JS function (which is ultimately where the memory gets grows when `malloc` calls `sbrk` to get more memory):
https://github.com/emscripten-core/emscripten/blob/0538c9dba690359baa7c09e99a7ff597796c4939/src/library.js#L171-L172

cheers,

sam

 

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/432220a3-fcc4-46db-901e-145deb1fcdd5n%40googlegroups.com.

[Brion Vibber]

On Mon, Aug 7, 2023 at 7:52 AM 'Michael Hagar' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

Pointers as returned from _malloc are relative to the beginning of the module's linear memory (ie, with the start at 0 for code inside Wasm or JS viewing through a typed array).

If the WebAssembly runtime needs to move the underlying buffer in the process address space (which can happen on a 32-bit system if not enough address space was initially reserved), this will be entirely transparent to WASM and JavaScript code in terms of pointers; the new buffer will contain the same data at the same locations, but be larger.

My understanding is that if you are passing around Typed Array views into the linear memory on the JS side, that those might become stale? Though I'm not 100% sure if that's current since Wasm came in and added its own method of underlying buffer growth. :D

--  brion