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

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.

https://docs.microsoft.com/dotnet/core/

MIT License

15.16k stars 4.72k forks source link

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

Open lambdageek opened 2 years ago

lambdageek commented 2 years ago

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

ghost commented 2 years ago

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:	-

ghost commented 2 years ago

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 commented 1 year ago

@lambdageek what is the state of this

cc @pavelsavara

lambdageek commented 1 year ago

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 commented 1 year ago

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.

pavelsavara commented 11 months ago

I think that

we will try to not have managed code on UI thread
there should be no JS on any but dedicated JSWebWorker thread
on JSWebWorker or deputy thread, we are idling in external loop by default. When timer or any other event ticks, we enter the mono thru GC barrier, like MONO_ENTER_GC_UNSAFE

One which is possibly missing it is mono_wasm_execute_timer

pavelsavara commented 9 months ago

To avoid blocking UI thread on GC, we could add another condition here. https://github.com/dotnet/runtime/blob/72604a4b56851a306a545a4fc7320db3a942398f/src/mono/browser/runtime/scheduling.ts#L56

And postpone mono job execution (also) when GC is running.

ghost commented 8 months ago

Tagging subscribers to this area: @brzvlad 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:	pavelsavara
Labels:	`arch-wasm`, `area-GC-mono`, `area-VM-threading-mono`, `os-browser`
Milestone:	9.0.0

lewing commented 8 months ago

cc @steveisok

pavelsavara commented 6 months ago

If we are able to detach the UI thread from Mono, it would be preferable solution of this problem. See https://github.com/dotnet/runtime/issues/100411

pavelsavara commented 6 months ago

To be able to postpone calls to mono_wasm_gc_lock we also need to postpone whole Blazor renderBatch via setTimeout Currently it happens synchronously I think.