Repository navigation
[browser][MT] JS Interop should respect GC pauses #76963
Description
Block threads (esp the main thread) from entering the runtime from the JS event loop when a GC Stop-The-World is active.
The thread should safepoint in native, or (better) somehow defer its work and return to the JS event loop
Current offenders are
- reflection in
init_managed_exports mono_wasm_gc_lock,mono_wasm_gc_unlockused by Blazormono_wasm_read_as_bool_or_null_unsafeused by Blazor- GC roots in hybrid globalization
Activity
[-]JS Interop should respect GC pauses[/-][+][wasm-mt] JS Interop should respect GC pauses[/+]lewing commentedon Jul 11, 2023
@lambdageek what is the state of this
cc @pavelsavara
lambdageek commentedon Jul 11, 2023
Basically wishlist.
I think we have GC Unsafe transitions on all the places where JS runtime code enters native. And managed code has transitions on the native-to- managed wrappers, so calling managed from JS will likewise safepoint.
So the remaining part of this is to design something new that is Promise-aware so that async apis can wait in JS instead of blocking.
pavelsavara commentedon Jul 11, 2023
Perhaps mono GC could export unresolved Promise. JS would await that promise instead of blocking, before running any managed callbacks. That also assumes that the callback are async in nature. I'm not sure that all DOM or networking events are.[-][wasm-mt] JS Interop should respect GC pauses[/-][+][browser][MT] JS Interop should respect GC pauses[/+]pavelsavara commentedon Nov 9, 2023
pavelsavara commentedon Jan 14, 2024
lewing commentedon Feb 9, 2024
cc @steveisok
pavelsavara commentedon Mar 28, 2024
If we are able to detach the UI thread from Mono, it would be preferable solution of this problem. See #100411
pavelsavara commentedon Mar 28, 2024
To be able to postpone calls to
mono_wasm_gc_lockwe also need to postpone whole BlazorrenderBatchviasetTimeoutCurrently it happens synchronously I think.