Don't enable shared memory by default with Wasm atomics by daxpedda · Pull Request #147225 · rust-lang/rust

daxpedda · 2025-10-01T13:19:13Z

This prepares us for a future where LLVM eventually stabilizes the atomics target feature, in which case we don't want to inflate atomics with threads. Otherwise users would be stuck with shared memory even when they don't want it/need it.

Context

Currently the atomics target features is unstable and can't be used without re-building Std with it (-Zbuild-std).
Enabling the atomics target feature automatically enables shared memory.
Shared memory is required to actually allow multi-threading.
However, shared memory comes with a performance overhead when atomic instructions aren't able to be lowered to regular memory access instructions or when interacting with certain Web APIs.
So it is very undesirable to enable shared memory by default for the majority of users.

While it is possible to use atomics without shared memory, the question remains what use-case this scenario has.
The only one I can think of would involve multiple memories, where the main memory remains un-shared but a second shared memory exists. While Rust doesn't support multiple memories, it might be possible with inline assembly (#136382).

So alternatively, we might consider not enabling atomics by default even when LLVM does. In which case everything would remain the same.

This will break current Web multi-threading users. To address this they can add the following RUSTFLAGS:

-Clink-arg=--shared-memory -Clink-arg=--max-memory=1073741824 -Clink-arg=--import-memory -Clink-arg=--export=__wasm_init_tls -Clink-arg=--export=__tls_size -Clink-arg=--export=__tls_align -Clink-arg=--export=__tls_base

We could add a new experimental flag that enables the right linker arguments for users, but I feel that's not in Rusts scope. Or like suggested before: a Rust-only threads target feature.

Addresses #77839.
r? @alexcrichton

rustbot · 2025-10-01T13:19:17Z

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

alexcrichton · 2025-10-01T14:21:12Z

Should the wasm32-wasip1-threads target specification perhaps get adjusted to pass these arguments by default? Otherwise that target won't actually produce a shared memory by default if I'm understanding this right. Otherwise though this looks reasonable to me, thanks!

daxpedda · 2025-10-01T14:41:34Z

AFAIK it already does:

rust/compiler/rustc_target/src/spec/targets/wasm32_wasip1_threads.rs

Lines 20 to 32 in 1e1a394

    
           options.add_pre_link_args( 
        
               LinkerFlavor::WasmLld(Cc::No), 
        
               &["--import-memory", "--export-memory", "--shared-memory"], 
        
           ); 
        
           options.add_pre_link_args( 
        
               LinkerFlavor::WasmLld(Cc::Yes), 
        
               &[ 
        
                   "--target=wasm32-wasip1-threads", 
        
                   "-Wl,--import-memory", 
        
                   "-Wl,--export-memory,", 
        
                   "-Wl,--shared-memory", 
        
               ], 
        
           );

bjorn3 · 2025-10-01T14:44:20Z

That is missing the --max-memory, which is mandatory for shared memories.

rustbot · 2025-10-01T15:44:03Z

These commits modify compiler targets.
(See the Target Tier Policy.)

daxpedda · 2025-10-01T15:45:27Z

That is missing the --max-memory, which is mandatory for shared memories.

Its interesting that so many flags were overlapping then.
I added --max-memory to the affected targets.

alexcrichton · 2025-10-01T18:48:02Z

@bors: r+

bors · 2025-10-01T18:48:05Z

📌 Commit 3e8ce2b has been approved by alexcrichton

It is now in the queue for this repository.

… r=alexcrichton Don't enable shared memory by default with Wasm atomics This prepares us for a future where LLVM eventually stabilizes the atomics target feature, in which case we don't want to inflate atomics with threads. Otherwise users would be stuck with shared memory even when they don't want it/need it. ### Context Currently the atomics target features is unstable and can't be used without re-building Std with it (`-Zbuild-std`). Enabling the atomics target feature automatically enables shared memory. Shared memory is required to actually allow multi-threading. However, shared memory comes with a performance overhead when atomic instructions aren't able to be lowered to regular memory access instructions or when interacting with certain Web APIs. So it is very undesirable to enable shared memory by default for the majority of users. While it is possible to use atomics without shared memory, the question remains what use-case this scenario has. The only one I can think of would involve multiple memories, where the main memory remains un-shared but a second shared memory exists. While Rust doesn't support multiple memories, it might be possible with inline assembly (rust-lang#136382). So alternatively, we might consider *not* enabling atomics by default even when LLVM does. In which case everything would remain the same. --- This will break current Web multi-threading users. To address this they can add the following `RUSTFLAGS`: ``` -Clink-args=--shared-memory,--max-memory=1073741824,--import-memory,--export=__wasm_init_tls,--export=__tls_size,--export=__tls_align,--export=__tls_base ``` We could add a new experimental flag that enables the right linker arguments for users, but I feel that's not in Rusts scope. Or like suggested before: a Rust-only `threads` target feature. Addresses rust-lang#77839. r? `@alexcrichton`

Rollup of 10 pull requests Successful merges: - #146281 (Support `#[rustc_align_static]` inside `thread_local!`) - #146535 (mbe: Implement `unsafe` attribute rules) - #146585 (indexing: reword help) - #147004 (Tweak handling of "struct like start" where a struct isn't supported) - #147221 (Forbid `//@ compile-flags: -Cincremental=` in tests) - #147225 (Don't enable shared memory by default with Wasm atomics) - #147227 (implement `Box::take`) - #147231 (Extending `#[rustc_force_inline]` to be applicable to inherent methods) - #147233 (Initialize llvm submodule if not already the case to run citool) - #147236 (Update books) r? `@ghost` `@rustbot` modify labels: rollup

… r=alexcrichton Don't enable shared memory by default with Wasm atomics This prepares us for a future where LLVM eventually stabilizes the atomics target feature, in which case we don't want to inflate atomics with threads. Otherwise users would be stuck with shared memory even when they don't want it/need it. ### Context Currently the atomics target features is unstable and can't be used without re-building Std with it (`-Zbuild-std`). Enabling the atomics target feature automatically enables shared memory. Shared memory is required to actually allow multi-threading. However, shared memory comes with a performance overhead when atomic instructions aren't able to be lowered to regular memory access instructions or when interacting with certain Web APIs. So it is very undesirable to enable shared memory by default for the majority of users. While it is possible to use atomics without shared memory, the question remains what use-case this scenario has. The only one I can think of would involve multiple memories, where the main memory remains un-shared but a second shared memory exists. While Rust doesn't support multiple memories, it might be possible with inline assembly (rust-lang#136382). So alternatively, we might consider *not* enabling atomics by default even when LLVM does. In which case everything would remain the same. --- This will break current Web multi-threading users. To address this they can add the following `RUSTFLAGS`: ``` -Clink-args=--shared-memory,--max-memory=1073741824,--import-memory,--export=__wasm_init_tls,--export=__tls_size,--export=__tls_align,--export=__tls_base ``` We could add a new experimental flag that enables the right linker arguments for users, but I feel that's not in Rusts scope. Or like suggested before: a Rust-only `threads` target feature. Addresses rust-lang#77839. r? ``@alexcrichton``

… r=alexcrichton Don't enable shared memory by default with Wasm atomics This prepares us for a future where LLVM eventually stabilizes the atomics target feature, in which case we don't want to inflate atomics with threads. Otherwise users would be stuck with shared memory even when they don't want it/need it. ### Context Currently the atomics target features is unstable and can't be used without re-building Std with it (`-Zbuild-std`). Enabling the atomics target feature automatically enables shared memory. Shared memory is required to actually allow multi-threading. However, shared memory comes with a performance overhead when atomic instructions aren't able to be lowered to regular memory access instructions or when interacting with certain Web APIs. So it is very undesirable to enable shared memory by default for the majority of users. While it is possible to use atomics without shared memory, the question remains what use-case this scenario has. The only one I can think of would involve multiple memories, where the main memory remains un-shared but a second shared memory exists. While Rust doesn't support multiple memories, it might be possible with inline assembly (rust-lang#136382). So alternatively, we might consider *not* enabling atomics by default even when LLVM does. In which case everything would remain the same. --- This will break current Web multi-threading users. To address this they can add the following `RUSTFLAGS`: ``` -Clink-args=--shared-memory,--max-memory=1073741824,--import-memory,--export=__wasm_init_tls,--export=__tls_size,--export=__tls_align,--export=__tls_base ``` We could add a new experimental flag that enables the right linker arguments for users, but I feel that's not in Rusts scope. Or like suggested before: a Rust-only `threads` target feature. Addresses rust-lang#77839. r? `@alexcrichton`

Rollup of 9 pull requests Successful merges: - #146281 (Support `#[rustc_align_static]` inside `thread_local!`) - #146535 (mbe: Implement `unsafe` attribute rules) - #146585 (indexing: reword help) - #147004 (Tweak handling of "struct like start" where a struct isn't supported) - #147221 (Forbid `//@ compile-flags: -Cincremental=` in tests) - #147225 (Don't enable shared memory by default with Wasm atomics) - #147227 (implement `Box::take`) - #147233 (Initialize llvm submodule if not already the case to run citool) - #147236 (Update books) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #147225 - daxpedda:wasm-u-u-atomics-threads, r=alexcrichton Don't enable shared memory by default with Wasm atomics This prepares us for a future where LLVM eventually stabilizes the atomics target feature, in which case we don't want to inflate atomics with threads. Otherwise users would be stuck with shared memory even when they don't want it/need it. ### Context Currently the atomics target features is unstable and can't be used without re-building Std with it (`-Zbuild-std`). Enabling the atomics target feature automatically enables shared memory. Shared memory is required to actually allow multi-threading. However, shared memory comes with a performance overhead when atomic instructions aren't able to be lowered to regular memory access instructions or when interacting with certain Web APIs. So it is very undesirable to enable shared memory by default for the majority of users. While it is possible to use atomics without shared memory, the question remains what use-case this scenario has. The only one I can think of would involve multiple memories, where the main memory remains un-shared but a second shared memory exists. While Rust doesn't support multiple memories, it might be possible with inline assembly (#136382). So alternatively, we might consider *not* enabling atomics by default even when LLVM does. In which case everything would remain the same. --- This will break current Web multi-threading users. To address this they can add the following `RUSTFLAGS`: ``` -Clink-args=--shared-memory,--max-memory=1073741824,--import-memory,--export=__wasm_init_tls,--export=__tls_size,--export=__tls_align,--export=__tls_base ``` We could add a new experimental flag that enables the right linker arguments for users, but I feel that's not in Rusts scope. Or like suggested before: a Rust-only `threads` target feature. Addresses #77839. r? ``@alexcrichton``

Rollup of 9 pull requests Successful merges: - rust-lang/rust#146281 (Support `#[rustc_align_static]` inside `thread_local!`) - rust-lang/rust#146535 (mbe: Implement `unsafe` attribute rules) - rust-lang/rust#146585 (indexing: reword help) - rust-lang/rust#147004 (Tweak handling of "struct like start" where a struct isn't supported) - rust-lang/rust#147221 (Forbid `//@ compile-flags: -Cincremental=` in tests) - rust-lang/rust#147225 (Don't enable shared memory by default with Wasm atomics) - rust-lang/rust#147227 (implement `Box::take`) - rust-lang/rust#147233 (Initialize llvm submodule if not already the case to run citool) - rust-lang/rust#147236 (Update books) r? `@ghost` `@rustbot` modify labels: rollup

… r=alexcrichton Don't enable shared memory by default with Wasm atomics This prepares us for a future where LLVM eventually stabilizes the atomics target feature, in which case we don't want to inflate atomics with threads. Otherwise users would be stuck with shared memory even when they don't want it/need it. ### Context Currently the atomics target features is unstable and can't be used without re-building Std with it (`-Zbuild-std`). Enabling the atomics target feature automatically enables shared memory. Shared memory is required to actually allow multi-threading. However, shared memory comes with a performance overhead when atomic instructions aren't able to be lowered to regular memory access instructions or when interacting with certain Web APIs. So it is very undesirable to enable shared memory by default for the majority of users. While it is possible to use atomics without shared memory, the question remains what use-case this scenario has. The only one I can think of would involve multiple memories, where the main memory remains un-shared but a second shared memory exists. While Rust doesn't support multiple memories, it might be possible with inline assembly (rust-lang#136382). So alternatively, we might consider *not* enabling atomics by default even when LLVM does. In which case everything would remain the same. --- This will break current Web multi-threading users. To address this they can add the following `RUSTFLAGS`: ``` -Clink-args=--shared-memory,--max-memory=1073741824,--import-memory,--export=__wasm_init_tls,--export=__tls_size,--export=__tls_align,--export=__tls_base ``` We could add a new experimental flag that enables the right linker arguments for users, but I feel that's not in Rusts scope. Or like suggested before: a Rust-only `threads` target feature. Addresses rust-lang#77839. r? ``@alexcrichton``

…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#146281 (Support `#[rustc_align_static]` inside `thread_local!`) - rust-lang#146535 (mbe: Implement `unsafe` attribute rules) - rust-lang#146585 (indexing: reword help) - rust-lang#147004 (Tweak handling of "struct like start" where a struct isn't supported) - rust-lang#147221 (Forbid `//@ compile-flags: -Cincremental=` in tests) - rust-lang#147225 (Don't enable shared memory by default with Wasm atomics) - rust-lang#147227 (implement `Box::take`) - rust-lang#147233 (Initialize llvm submodule if not already the case to run citool) - rust-lang#147236 (Update books) r? `@ghost` `@rustbot` modify labels: rollup

… r=alexcrichton Don't enable shared memory by default with Wasm atomics This prepares us for a future where LLVM eventually stabilizes the atomics target feature, in which case we don't want to inflate atomics with threads. Otherwise users would be stuck with shared memory even when they don't want it/need it. ### Context Currently the atomics target features is unstable and can't be used without re-building Std with it (`-Zbuild-std`). Enabling the atomics target feature automatically enables shared memory. Shared memory is required to actually allow multi-threading. However, shared memory comes with a performance overhead when atomic instructions aren't able to be lowered to regular memory access instructions or when interacting with certain Web APIs. So it is very undesirable to enable shared memory by default for the majority of users. While it is possible to use atomics without shared memory, the question remains what use-case this scenario has. The only one I can think of would involve multiple memories, where the main memory remains un-shared but a second shared memory exists. While Rust doesn't support multiple memories, it might be possible with inline assembly (rust-lang#136382). So alternatively, we might consider *not* enabling atomics by default even when LLVM does. In which case everything would remain the same. --- This will break current Web multi-threading users. To address this they can add the following `RUSTFLAGS`: ``` -Clink-args=--shared-memory,--max-memory=1073741824,--import-memory,--export=__wasm_init_tls,--export=__tls_size,--export=__tls_align,--export=__tls_base ``` We could add a new experimental flag that enables the right linker arguments for users, but I feel that's not in Rusts scope. Or like suggested before: a Rust-only `threads` target feature. Addresses rust-lang#77839. r? ``@alexcrichton``

…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#146281 (Support `#[rustc_align_static]` inside `thread_local!`) - rust-lang#146535 (mbe: Implement `unsafe` attribute rules) - rust-lang#146585 (indexing: reword help) - rust-lang#147004 (Tweak handling of "struct like start" where a struct isn't supported) - rust-lang#147221 (Forbid `//@ compile-flags: -Cincremental=` in tests) - rust-lang#147225 (Don't enable shared memory by default with Wasm atomics) - rust-lang#147227 (implement `Box::take`) - rust-lang#147233 (Initialize llvm submodule if not already the case to run citool) - rust-lang#147236 (Update books) r? `@ghost` `@rustbot` modify labels: rollup

Rollup of 9 pull requests Successful merges: - rust-lang/rust#146281 (Support `#[rustc_align_static]` inside `thread_local!`) - rust-lang/rust#146535 (mbe: Implement `unsafe` attribute rules) - rust-lang/rust#146585 (indexing: reword help) - rust-lang/rust#147004 (Tweak handling of "struct like start" where a struct isn't supported) - rust-lang/rust#147221 (Forbid `//@ compile-flags: -Cincremental=` in tests) - rust-lang/rust#147225 (Don't enable shared memory by default with Wasm atomics) - rust-lang/rust#147227 (implement `Box::take`) - rust-lang/rust#147233 (Initialize llvm submodule if not already the case to run citool) - rust-lang/rust#147236 (Update books) r? `@ghost` `@rustbot` modify labels: rollup

…ce/xet-core#554) App still has issues at runtime

Shared memory with Wasm atomics is disabled by default since rust-lang/rust#147225. This adds the necessary flags to enable it.

This fixes the example for the breaking change introduced by: rust-lang/rust#147225

Rollup of 9 pull requests Successful merges: - rust-lang/rust#146281 (Support `#[rustc_align_static]` inside `thread_local!`) - rust-lang/rust#146535 (mbe: Implement `unsafe` attribute rules) - rust-lang/rust#146585 (indexing: reword help) - rust-lang/rust#147004 (Tweak handling of "struct like start" where a struct isn't supported) - rust-lang/rust#147221 (Forbid `//@ compile-flags: -Cincremental=` in tests) - rust-lang/rust#147225 (Don't enable shared memory by default with Wasm atomics) - rust-lang/rust#147227 (implement `Box::take`) - rust-lang/rust#147233 (Initialize llvm submodule if not already the case to run citool) - rust-lang/rust#147236 (Update books) r? `@ghost` `@rustbot` modify labels: rollup

@alexcrichton

…xcrichton Wasm: remove implicit `__heap_base`/`__data_end` exports This is kind of a follow-up to rust-lang#147225. Currently `__heap_base`/`__data_end` globals are implicitly exported on `wasm*-unknown-unknown` and `wasm32v1-none`, even though they were only used for Wasm multi-threading, requiring the atomics target feature and shared memory. Instead users should explicitly opt-in to these features, in which case toolchains, like `wasm-bindgen`, would require some linker flags. After this PR the following would be required for multi-threading support in `wasm-bindgen`: ``` -Clink-arg=--shared-memory -Clink-arg=--max-memory=1073741824 -Clink-arg=--import-memory -Clink-arg=--export=__heap_base -Clink-arg=--export=__wasm_init_tls -Clink-arg=--export=__tls_size -Clink-arg=--export=__tls_align -Clink-arg=--export=__tls_base ``` You will notice that the only new addition is `--export=__heap_base`, apparently `wasm-bindgen` doesn't need `__data_end` anymore (I didn't dig into the original motivation). --- For context why `wasm-bindgen` needed access to `__heap_base`: There is currently no mechanism in the Wasm tool conventions that automatically allocates the stack for every thread (e.g. via the `start` function). So `wasm-bindgen` has to explicitly call `malloc` to allocate the stack on the new thread. However, calling `malloc` itself requires a stack to be present! With the help of `__heap_base` `wasm-bindgen` constructs a temporary stack to make this work. This is obviously quite hacky. A newer implementation could go a different route: e.g. allocate the threads stack in the main thread and passing the right information on, not requiring access to `__heap_base` at all (and avoiding this really messy workaround). I should also note here that e.g. [`js-bindgen`](https://github.com/wasm-bindgen/js-bindgen), the successor currently being worked on, doesn't need any of these exports because it doesn't rely on post-processing. In which case all of these variables can be accessed by name at link-time, instead of requiring the linker to export each variable for post-processing to find them by name. That is to say: all these workaround are toolchain-specific and not universal to the Wasm targets. --- r? @alexcrichton

@alexcrichton

…xcrichton Wasm: remove implicit `__heap_base`/`__data_end` exports This is kind of a follow-up to rust-lang#147225. Currently `__heap_base`/`__data_end` globals are implicitly exported on `wasm*-unknown-unknown` and `wasm32v1-none`, even though they were only used for Wasm multi-threading, requiring the atomics target feature and shared memory. Instead users should explicitly opt-in to these features, in which case toolchains, like `wasm-bindgen`, would require some linker flags. After this PR the following would be required for multi-threading support in `wasm-bindgen`: ``` -Clink-arg=--shared-memory -Clink-arg=--max-memory=1073741824 -Clink-arg=--import-memory -Clink-arg=--export=__heap_base -Clink-arg=--export=__wasm_init_tls -Clink-arg=--export=__tls_size -Clink-arg=--export=__tls_align -Clink-arg=--export=__tls_base ``` You will notice that the only new addition is `--export=__heap_base`, apparently `wasm-bindgen` doesn't need `__data_end` anymore (I didn't dig into the original motivation). --- For context why `wasm-bindgen` needed access to `__heap_base`: There is currently no mechanism in the Wasm tool conventions that automatically allocates the stack for every thread (e.g. via the `start` function). So `wasm-bindgen` has to explicitly call `malloc` to allocate the stack on the new thread. However, calling `malloc` itself requires a stack to be present! With the help of `__heap_base` `wasm-bindgen` constructs a temporary stack to make this work. This is obviously quite hacky. A newer implementation could go a different route: e.g. allocate the threads stack in the main thread and passing the right information on, not requiring access to `__heap_base` at all (and avoiding this really messy workaround). I should also note here that e.g. [`js-bindgen`](https://github.com/wasm-bindgen/js-bindgen), the successor currently being worked on, doesn't need any of these exports because it doesn't rely on post-processing. In which case all of these variables can be accessed by name at link-time, instead of requiring the linker to export each variable for post-processing to find them by name. That is to say: all these workaround are toolchain-specific and not universal to the Wasm targets. --- r? @alexcrichton

@alexcrichton

…xcrichton Wasm: remove implicit `__heap_base`/`__data_end` exports This is kind of a follow-up to rust-lang#147225. Currently `__heap_base`/`__data_end` globals are implicitly exported on `wasm*-unknown-unknown` and `wasm32v1-none`, even though they were only used for Wasm multi-threading, requiring the atomics target feature and shared memory. Instead users should explicitly opt-in to these features, in which case toolchains, like `wasm-bindgen`, would require some linker flags. After this PR the following would be required for multi-threading support in `wasm-bindgen`: ``` -Clink-arg=--shared-memory -Clink-arg=--max-memory=1073741824 -Clink-arg=--import-memory -Clink-arg=--export=__heap_base -Clink-arg=--export=__wasm_init_tls -Clink-arg=--export=__tls_size -Clink-arg=--export=__tls_align -Clink-arg=--export=__tls_base ``` You will notice that the only new addition is `--export=__heap_base`, apparently `wasm-bindgen` doesn't need `__data_end` anymore (I didn't dig into the original motivation). --- For context why `wasm-bindgen` needed access to `__heap_base`: There is currently no mechanism in the Wasm tool conventions that automatically allocates the stack for every thread (e.g. via the `start` function). So `wasm-bindgen` has to explicitly call `malloc` to allocate the stack on the new thread. However, calling `malloc` itself requires a stack to be present! With the help of `__heap_base` `wasm-bindgen` constructs a temporary stack to make this work. This is obviously quite hacky. A newer implementation could go a different route: e.g. allocate the threads stack in the main thread and passing the right information on, not requiring access to `__heap_base` at all (and avoiding this really messy workaround). I should also note here that e.g. [`js-bindgen`](https://github.com/wasm-bindgen/js-bindgen), the successor currently being worked on, doesn't need any of these exports because it doesn't rely on post-processing. In which case all of these variables can be accessed by name at link-time, instead of requiring the linker to export each variable for post-processing to find them by name. That is to say: all these workaround are toolchain-specific and not universal to the Wasm targets. --- r? @alexcrichton

@alexcrichton

Rollup merge of #156174 - daxpedda:wasm-clear-exports, r=alexcrichton Wasm: remove implicit `__heap_base`/`__data_end` exports This is kind of a follow-up to #147225. Currently `__heap_base`/`__data_end` globals are implicitly exported on `wasm*-unknown-unknown` and `wasm32v1-none`, even though they were only used for Wasm multi-threading, requiring the atomics target feature and shared memory. Instead users should explicitly opt-in to these features, in which case toolchains, like `wasm-bindgen`, would require some linker flags. After this PR the following would be required for multi-threading support in `wasm-bindgen`: ``` -Clink-arg=--shared-memory -Clink-arg=--max-memory=1073741824 -Clink-arg=--import-memory -Clink-arg=--export=__heap_base -Clink-arg=--export=__wasm_init_tls -Clink-arg=--export=__tls_size -Clink-arg=--export=__tls_align -Clink-arg=--export=__tls_base ``` You will notice that the only new addition is `--export=__heap_base`, apparently `wasm-bindgen` doesn't need `__data_end` anymore (I didn't dig into the original motivation). --- For context why `wasm-bindgen` needed access to `__heap_base`: There is currently no mechanism in the Wasm tool conventions that automatically allocates the stack for every thread (e.g. via the `start` function). So `wasm-bindgen` has to explicitly call `malloc` to allocate the stack on the new thread. However, calling `malloc` itself requires a stack to be present! With the help of `__heap_base` `wasm-bindgen` constructs a temporary stack to make this work. This is obviously quite hacky. A newer implementation could go a different route: e.g. allocate the threads stack in the main thread and passing the right information on, not requiring access to `__heap_base` at all (and avoiding this really messy workaround). I should also note here that e.g. [`js-bindgen`](https://github.com/wasm-bindgen/js-bindgen), the successor currently being worked on, doesn't need any of these exports because it doesn't rely on post-processing. In which case all of these variables can be accessed by name at link-time, instead of requiring the linker to export each variable for post-processing to find them by name. That is to say: all these workaround are toolchain-specific and not universal to the Wasm targets. --- r? @alexcrichton

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 1, 2025

rustbot assigned alexcrichton Oct 1, 2025

This comment has been minimized.

Sign in to view

Don't enable shared memory with Wasm atomics

5b809b3

daxpedda force-pushed the wasm-u-u-atomics-threads branch from 6f67cc5 to 5b809b3 Compare October 1, 2025 13:36

Adjust WASI and WALI targets

3e8ce2b

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 1, 2025

Zalathar mentioned this pull request Oct 2, 2025

Rollup of 10 pull requests #147253

Closed

matthiaskrgr mentioned this pull request Oct 2, 2025

Rollup of 9 pull requests #147256

Closed

jhpratt mentioned this pull request Oct 2, 2025

Rollup of 10 pull requests #147260

Closed

matthiaskrgr mentioned this pull request Oct 2, 2025

Rollup of 9 pull requests #147261

Merged

bors merged commit 8a18176 into rust-lang:master Oct 2, 2025
10 checks passed

rustbot added this to the 1.92.0 milestone Oct 2, 2025

Spxg mentioned this pull request Oct 15, 2025

SharedArrayBuffer Not Working wasm-bindgen/wasm-bindgen#4739

Closed

jsgroth mentioned this pull request Oct 17, 2025

jgenesis-web error jsgroth/jgenesis#578

Closed

Wrufesh mentioned this pull request Nov 4, 2025

wasm thread: TypeError: [object Int32Array] is not a shared typed array. huggingface/xet-core#554

Closed

RReverser mentioned this pull request Nov 10, 2025

Broken since nightly-2025-10-03: DataCloneError RReverser/wasm-bindgen-rayon#33

Closed

laurmaedje mentioned this pull request Nov 13, 2025

Update Rust nightly version used in tests typst/typst#7366

Merged

nsarlin-zama mentioned this pull request Nov 19, 2025

chore: update msrv to 1.91.1 zama-ai/tfhe-rs#3022

Merged

9SMTM6 added a commit to 9SMTM6/mcmc-demo that referenced this pull request Nov 20, 2025

Fix "linking" issue based on rust-lang/rust#147225 (through huggingfa…

3367ab8

…ce/xet-core#554) App still has issues at runtime

Wrufesh mentioned this pull request Nov 28, 2025

Update RUSTFLAGS for wasm build script huggingface/xet-core#584

Merged

seanses pushed a commit to huggingface/xet-core that referenced this pull request Dec 3, 2025

Update RUSTFLAGS for wasm build script (#584)

e94270f

Shared memory with Wasm atomics is disabled by default since rust-lang/rust#147225. This adds the necessary flags to enable it.

temeddix mentioned this pull request Dec 7, 2025

Containerize docs and demo cunarist/rinf#653

Merged

robtfm mentioned this pull request Jan 1, 2026

support 12-31 nightly decentraland/bevy-explorer#493

Merged

kettle11 added a commit to kettle11/cpal that referenced this pull request Jan 3, 2026

Fix AudioWorklet example

c82fec1

This fixes the example for the breaking change introduced by: rust-lang/rust#147225

kettle11 mentioned this pull request Jan 3, 2026

Fix AudioWorklet example RustAudio/cpal#1088

Merged

roderickvd pushed a commit to RustAudio/cpal that referenced this pull request Jan 3, 2026

Fix AudioWorklet example (#1088)

c6e2461

This fixes the example for the breaking change introduced by: rust-lang/rust#147225

Twey mentioned this pull request Jan 15, 2026

Update to recent nightly Rust compiler linera-io/linera-protocol#5264

Open

CorvusPrudens mentioned this pull request Jan 26, 2026

bevy run web --unstable multi-threading panics TheBevyFlock/bevy_cli#642

Closed

deuszx mentioned this pull request Mar 3, 2026

Update Rust tolchains linera-io/linera-protocol#5554

Closed

daxpedda mentioned this pull request May 5, 2026

Wasm: remove implicit __heap_base/__data_end exports #156174

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Don't enable shared memory by default with Wasm atomics#147225

Don't enable shared memory by default with Wasm atomics#147225
bors merged 2 commits intorust-lang:masterfrom
daxpedda:wasm-u-u-atomics-threads

daxpedda commented Oct 1, 2025 •

edited

Loading

Uh oh!

rustbot commented Oct 1, 2025

Uh oh!

This comment has been minimized.

alexcrichton commented Oct 1, 2025

Uh oh!

daxpedda commented Oct 1, 2025

Uh oh!

bjorn3 commented Oct 1, 2025

Uh oh!

rustbot commented Oct 1, 2025

Uh oh!

daxpedda commented Oct 1, 2025

Uh oh!

alexcrichton commented Oct 1, 2025

Uh oh!

bors commented Oct 1, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Uh oh!

Conversation

daxpedda commented Oct 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Context

Uh oh!

rustbot commented Oct 1, 2025

Uh oh!

This comment has been minimized.

alexcrichton commented Oct 1, 2025

Uh oh!

daxpedda commented Oct 1, 2025

Uh oh!

bjorn3 commented Oct 1, 2025

Uh oh!

rustbot commented Oct 1, 2025

Uh oh!

daxpedda commented Oct 1, 2025

Uh oh!

alexcrichton commented Oct 1, 2025

Uh oh!

bors commented Oct 1, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

daxpedda commented Oct 1, 2025 •

edited

Loading