Any deep-dive learning resources for Emscripten?

[chris goyette]

I’ve been through the official API and documentation for Emscripten, but they don’t cover the things I’m really curious about.

What I’m looking for are lower-level resources: explanations of how the memory model works, what’s actually happening when crossing the WASM/JS boundary, and how memory lifetimes are handled.

For example, it’s still unclear to me exactly *when* the JS barrier is crossed or what guarantees exist around memory in cases like this:

emscripten::val Float64Array = emscripten::val::global("Float64Array");
const double* src = reinterpret_cast<const double*>(someVectorOfDoubles.data());
emscripten::val view(emscripten::typed_memory_view(numDoubles, src));
jsArr.call<void>("set", view)

If you’ve found blog posts, talks, deep dives, or even good discussions on this topic, I’d really appreciate any pointers.

[Sam Clegg]

Your question seems to be specific to embind, which is specific optional part of emscripten. 

While not an answer to your specific question perhaps searching asking about embind specifically might yield better results in search engines etc.

Ultimately, if you really want to understand how embind works you going to want to dig deep in the `wire.h` and `bind.h` headers and the libembind.js JS code: https://github.com/emscripten-core/emscripten/blob/main/src/lib/libembind.js.  Beware, there is heavy use of C++ template magic in there!

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 visit https://groups.google.com/d/msgid/emscripten-discuss/45234e7e-43ad-4efd-b74d-17665a1e3cb1n%40googlegroups.com.

[chris goyette]

Thanks, Sam. That’s correct, the vast majority of my work has been with Embind. I want to understand when and how I am crossing the WASM boundary, and whether that even matters in practice. If I am iterating over an array that exists in JavaScript memory, cache locality still applies, and as long as the array is contiguous, it seems, naively, that it should not matter much whether the memory lives on the WASM heap or the JavaScript side.

What I do not understand is the access cost. How many function calls are involved, and are we likely to thrash the cache in the process? I honestly do not know. I do not expect anyone in the group to answer this in detail, but I anticipate using Emscripten far more often in the coming years, and these are things I will need to understand.

I have looked at wire.h and tried stepping through some of the relevant functions. Learning this way, by reading source code, is always difficult, especially when heavy template logic is involved. I was really hoping for a Udemy course or something similar, but everything I have found so far is very surface level. A conference talk would work just as well. Anything where someone explains the concepts directly would be far more effective than me fumbling my way through source code :P

[Sam Clegg]

You may be interested in this video from back in the day when embind was first created: https://www.youtube.com/watch?v=Dsgws5zJiwk

Many of the core concepts still apply I'm sure.

cheers,

sam

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/f2da182f-9417-4458-ac70-f7efe3a650a1n%40googlegroups.com.

[Brooke Vibber]

On Wed, Dec 10, 2025 at 8:38 AM chris goyette <chrisgoy...@gmail.com> wrote:

What I do not understand is the access cost. How many function calls are involved, and are we likely to thrash the cache in the process? I honestly do not know. I do not expect anyone in the group to answer this in detail, but I anticipate using Emscripten far more often in the coming years, and these are things I will need to understand.

I have looked at wire.h and tried stepping through some of the relevant functions. Learning this way, by reading source code, is always difficult, especially when heavy template logic is involved. I was really hoping for a Udemy course or something similar, but everything I have found so far is very surface level. A conference talk would work just as well. Anything where someone explains the concepts directly would be far more effective than me fumbling my way through source code :P

There was a great talk some years back which ...... I believe is this one:

https://www.youtube.com/watch?v=Dsgws5zJiwk

It's from 2014 so it talks about asm.js and such first -- the embind stuff comes in about 10 minutes in. IIRC the embind internals are pretty much the same as they were then and this goes into some more details on how it works under the hood which I think should help demystify it. :)

The bits on 'wire types' and embind's handles for JavaScript objects should help clarify memory management / lifetime / boundary.

Since much of the embind magic is set up by templates it's hard to see the costs from the high-level view indeed. :) Couple quick things off the to of my head from previous times working with embind:

In general, passing around a JavaScript object by reference is very cheap because you're just passing a handle id wrapped in an emscripten::val -- while actually accessing data through it will end up calling through to JavaScript. The JS side of embind keeps a big array I think with the handle -> object references. Integers and floats? Also cheap. Meanwhile passing strings or buffers/arrays to/from JavaScript is  expensive because it requires copying/conversion of data types. 

Data you export as a memory view becomes a Typed Array view into the WebAssembly memory, and is *very cheap* to return and to access. However it's your responsibility to manage the lifetime of the view responsibly compared to the lifetime of the underlying data -- if you free and reuse the underlying data while the view is still active it will show incorrect data.

-- brooke