[browser][coreclr] run finalizers on browser timer

[radekdoulik]

we are single threaded on browser/wasm. so we will need to run finalizers from main thread at the convenient point in time, similar as in mono

@lewing please add more details of how it is currently handled in mono runtime

[dotnet-policy-service]

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

[maraf]

NativeAOT-LLVM implemented it, although I don't remember details

[jkotas]

NativeAOT-LLVM implemented it, although I don't remember details

dotnet/runtimelab#2634

[pavelsavara]

If we consider running finalizers from synchronous code like NAOT_LLVM, we would also benefit from doing it for Mono in same way.
Our users are surprised that calling GC.Collect() from tight synchronous loop "doesn't work" when there are objects in finalizer queue.

The existing solution is to call the finalizer from setTimeout from JS.
For WASI the solution is to use wasi:clock and schedule wakeup callback. Especially with WASIp3 it should be fine.

[SingleAccretion]

Asynchronous finalizers imply throwing PNSE from WaitForPendingFinalizers.

Asynchronous finalizers also imply that apps (esp. on WASI) that don't yield to the host event loop would have a by-design leak built-in (without any way to remedy it, apart from avoiding any finalization entirely). I think that's a hard-to-justify experience.

[jkotas]

Running finalizers on exit from allocation helper is bug prone. You cannot tell whether the code that happens to be on the thread is going to interfere with the code that the finalizer code is going to run. It is the same fundamental problem as COM STA message pumping inside RPC calls where almost arbitrary code can start running on the thread while your code is calling out somewhere else.

I think running finalizers on exit from allocation helper is fine for experimentation, but I do not think it is something we would want to ship as a supported solution.

Single threaded app models have to cooperate by running the finalizers in their top-level dispatch loop.

[SingleAccretion]

Single threaded app models have to cooperate by running the finalizers in their top-level dispatch loop.

My main worry is what to do if there is no top-level dispatch loop. It is not a big problem for browser (the browser doesn't work well if you don't return to the event loop), but are we saying that basically only async main/exports are going to be the supported (non-leaky scenario) for ST WASM in general? Should we throw for non-async main/exports?

[jkotas]

You can hit the problem with async Main too. Any synchronous code that produces large amount of finalizable garbage without going to the top-level dispatch loop has this problem.

[pavelsavara]

Asynchronous finalizers imply throwing PNSE from WaitForPendingFinalizers.

On Mono ST this is NOP rather than PNSE. It would break too many existing codebases.

apps that don't yield to the host event loop would have a by-design leak

Yes. It's much more likely that this would be tight loop in user code.
We get such bug reports for mono/browser. "why GC doesn't work" - because finalizers are holding the rest of the graph alive.

(esp. on WASI)

For WASIp3 we would abandon synchronous PollWasiEventLoopUntilResolved and yield to host.

For WASIp2, we implement the synchronous loop

It allows you to create timer that would be called. I think lib-c pollables are resolved too, because lib-c sockets works.
And so we could schedule mono_runtime_do_background_work for later by registering for wasi:clock pollable from C with time zero (next tick).

Looking at the current code it's called in-line for WASI and that's wrong.

runtime/src/mono/mono/metadata/gc.c

Lines 668 to 672 in 0001e1c

	#if defined(HOST_WASI) && defined(DISABLE_THREADS)
	mono_runtime_do_background_work ();
	#elif defined(HOST_WASM) && defined(DISABLE_THREADS)
	mono_main_thread_schedule_background_job (mono_runtime_do_background_work);
	#else

I don't think we have bandwidth to fix it for WASIp2 and I would rather wait for WASIp3.

[SingleAccretion]

For WASIp3 we would abandon synchronous PollWasiEventLoopUntilResolved and yield to host.

The yield points would still need to be explicit (or "implicitly explicit" if we end up using the host magic with suspendable threads - it would still need to be some kind of wait call). It would be the same system as browser's event loop with the same problems.

My comment w.r.t. WASI was more so that in WASI it's not clear to me that an application which doesn't yield to the host is fundamentally "broken" (unlike on browser). E. g. if I were to write an interactive CUI program (al'a LLDB) which does while (line = Console.ReadLine()) { ... } (sync IO all the way down), it would only work with suspendable threads (equivalent of the COM message pumping Jan mentioned above).

[pavelsavara]

The yield points would still need to be explicit
with the same problems.

do you mean "What Color is Your Function" @SingleAccretion ?

magic with suspendable threads

for MT guest, we should not be able to tell the difference how the host does the magic. Also for MT guest we would run finalizer on guest thread.

for ST guest, I'm not friends with wait. Because I'm scared of host->guest re-entrance "in the middle" of unrelated call stack. Which would lead to same state corruption that finalizer code could cause, same as Jan said.

[pavelsavara]

I think that async main on ST is good tradeoff for async HTTP, async Socket, tasks on "threadpool" and other things we are used to as C# developers. If we allowed blocking on ST, those things would not make progress until that wait finished. Also, you could write code that would cause deadlock, if you assume "another thread" would wake this wait. That is, if we disable re-entrance.