Add WebAssembly overview aimed at JIT developers #120850
Conversation
github-actions
bot
added
the
area-CodeGen-coreclr
There was a problem hiding this comment.
Pull Request Overview
Adds a new documentation file providing a conceptual and practical overview of WebAssembly (WASM) targeted at JIT developers.
- Introduces WASM motivations and design priorities.
- Explains core concepts (modules, memory, control flow, function tables, traps, SIMD, threading, async).
- Highlights areas relevant to JIT integration (module structure, signatures, control flow transformation).
|
|
||
| Each host "thread" in practice has its own separate instance of the application module(s), and each instance has its own function table, global variables, and imports/exports. These threads then coordinate by sharing a single linear memory and using a mix of host imports (like a socket API) and atomics/fences. | ||
|
|
||
| It is necessary for an application to ensure that any changes to the function table are synchronized between threads, and any global variable changes need to be manually synchronized between threads (either by storing them in shared linear memory, or via RPC). ⚠️ All WASM global variables are effectively TLS variables. As a result of each instance having its own function table, function pointers are effectively thread-local! ⚠️ |
There was a problem hiding this comment.
[nitpick] The statement 'All WASM global variables are effectively TLS variables' may mislead; globals are per-module-instance and multiple threads can share an instance (e.g. via structured cloning or instantiation patterns) or intentionally instantiate separately. Clarify that per-instance isolation makes globals behave like thread-local only when each thread creates its own instance; when sharing an instance, globals are shared and need atomic synchronization if concurrently accessed.
| It is necessary for an application to ensure that any changes to the function table are synchronized between threads, and any global variable changes need to be manually synchronized between threads (either by storing them in shared linear memory, or via RPC). ⚠️ All WASM global variables are effectively TLS variables. As a result of each instance having its own function table, function pointers are effectively thread-local! ⚠️ | |
| It is necessary for an application to ensure that any changes to the function table are synchronized between threads, and any global variable changes need to be manually synchronized between threads (either by storing them in shared linear memory, or via RPC). ⚠️ WASM global variables are per-module-instance. If each thread creates its own instance, globals behave like thread-local storage (TLS). However, if multiple threads share a module instance (e.g., via structured cloning or certain instantiation patterns), globals are shared and concurrent access requires atomic synchronization. As a result of each instance having its own function table, function pointers are effectively thread-local only when instances are not shared! ⚠️ |
Copilot uses AI. Check for mistakes.
There was a problem hiding this comment.
Is this actually true? It seems like it would violate concurrency/safety guarantees in the JS spec if it were true.
There was a problem hiding this comment.
I can't find any evidence that this is true.
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
3 participants
No description provided.