[browser][MT] JS Interop should respect GC pauses

[lambdageek]

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_unlock used by Blazor
• mono_wasm_read_as_bool_or_null_unsafe used by Blazor
• GC roots in hybrid globalization

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

null

Author:	lambdageek
Assignees:	-
Labels:	area-GC-coreclr
Milestone:	-

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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

Author:	lambdageek
Assignees:	-
Labels:	arch-wasm, area-System.Runtime.InteropServices.JavaScript
Milestone:	8.0.0

[lewing]

@lambdageek what is the state of this

cc @pavelsavara

[lambdageek]

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]

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.