[browser][coreCLR] finalizer on a browser event loop #123629

pavelsavara · 2026-01-26T16:08:19Z

Fixes #114096

dotnet-policy-service · 2026-01-26T16:09:27Z

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

src/coreclr/vm/finalizerthread.cpp

src/coreclr/vm/ceemain.cpp

src/coreclr/vm/finalizerthread.cpp

src/coreclr/vm/finalizerthread.h

AaronRobinsonMSFT · 2026-01-26T17:40:56Z

src/coreclr/vm/finalizerthread.cpp

+            SString err;
+            ex->GetMessage(err);
+            LogErrorToHost("Error message: %s", err.GetUTF8());
+            abort();


I don't think calling abort() here is what we want. See FinalizerThread::FinalizerThreadStart where we will continue to loop.

I thought that we are supposed to "kill the process" when we see managed exception in the finalizer thread.

On other OS FinalizerThread::FinalizerThreadStart is running on different(main) thread than the finalizer.
How does the UNINSTALL_UNHANDLED_MANAGED_EXCEPTION_TRAP know that something failed on finalizer thread ?

I can use CrashDumpAndTerminateProcess(1); that is there in the macro instead of the abort()

when we see managed exception in the finalizer thread.

That is mostly true, but there are configurations here that we should only change with a clear comment on why. There is a fair bit of native infrastructure here that could trigger and we should be sensitive to that. Take a look at ManagedThreadBase_DispatchOuter and ManagedThreadBase_DispatchMiddle. @jkotas or @janvorli Can probably educate us both on the precise expectations here and what is reasonable to do.

I can use CrashDumpAndTerminateProcess(1); that is there in the macro instead of the abort()

That is a better place to start and what I would expect that API instead of abort() regardless of what we do. I might suggest CrashDumpAndTerminateProcess(ex->GetHR());.

How does the UNINSTALL_UNHANDLED_MANAGED_EXCEPTION_TRAP know that something failed on finalizer thread ?

I am not sure if I understand the question correctly. When a managed exception escapes the finalizer thread code, it is actually in a form of PAL_SEHException, so that macro catches it, reports the exception as unhandled and then calls the CrashDumpAndTerminateProcess to shutdown the runtime.

I've forgotten to mention that this is for Unix. On Windows, it is a SEH exception and the OS itself takes care of it (shutting down the process, generating dump)

I think UNINSTALL_UNHANDLED_MANAGED_EXCEPTION_TRAP is close to what we want for wasm.

You may want to actually test what happens when you throw in the finalizer on wasm. You should see unhandled exception message with stacktrace.

I think I see my mistake now. I got confused by ManagedThreadBase::KickOff. I thought it's creating another thread. I will continue tomorrow. Thank you so far!

src/coreclr/vm/finalizerthread.cpp

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

Co-authored-by: Aaron R Robinson <arobins@microsoft.com>

src/coreclr/vm/finalizerthread.cpp

BrzVlad · 2026-01-26T19:28:34Z

src/libraries/Common/tests/TestUtilities/System/PlatformDetection.cs


-        public static bool IsPreciseGcSupported => !IsMonoRuntime 
-                                                    && !IsBrowser; // TODO-WASM: https://github.com/dotnet/runtime/issues/114096
+        public static bool IsPreciseGcSupported => !IsMonoRuntime;


@janvorli Are we actually running successfully all tests assuming precise GC ? I know we are reporting quite a fair chunk of vars conservatively (I believe everything aside from the IL globals, args and locals)

IIRC, @davidwrighton has enabled conservative reporting of call arguments and temp vars, the rest should be reported precisely. David, have I forgotten about something?

I believe that the conservative reporting in the interpreter is still "precise" - for the definition of "precise" used by this property.

Precise GC here means that the runtime is not trying to interpret random values found on the stack as GC object references.

We are not running with fully precise GC today. I had an idea about how we could implement it semi-efficiently, but I haven't actually tried to see if it would work. However, the level of conservative GC we have today is extremely limited relative to what Mono was doing, so we might be close enough to precise GC semantics for nearly all the tests to pass. The notable detail is that I believe we are only reliably visibly imprecise for tests which check to see if a value got promoted (since our reporting will pin things that don't need pinning), and during the instruction after a call instruction. This is a MUCH smaller problem set than Mono had.

The notable detail is that I believe we are only reliably visibly imprecise for tests which check to see if a value got promoted (since our reporting will pin things that don't need pinning)

This sounds like we are just extending a lifetime within a method, correct? That does would count as imprecise GC. RyuJIT extends the lifetime within a method as well.

jkotas · 2026-01-26T21:51:48Z

src/coreclr/vm/finalizerthread.cpp

+    // Wait for work to do...

-        _ASSERTE(GetFinalizerThread()->PreemptiveGCDisabled());
 #ifdef _DEBUG


These GetFinalizerThread()->m_GCOnTransitionsOK = FALSE/TRUE should be moved up as well. It is important that the call to EnablePreemptiveGC is enclosed by these calls - it is a perf optimization for GC stress.

jkotas · 2026-01-26T21:52:09Z

src/coreclr/vm/finalizerthread.cpp

+        GCHeapUtilities::GetGCHeap()->CollectionCount(GCHeapUtilities::GetGCHeap()->GetMaxGeneration());
+    FinalizeAllObjects();
+
+    GetFinalizerThread()->DisablePreemptiveGC();


Should this be after the ifdef?

jkotas · 2026-01-26T21:53:27Z

src/coreclr/vm/finalizerthread.cpp

+}
+
+VOID FinalizerThread::FinalizerThreadWorkerIteration()
+{


Could you please add the expected contract here? (maybe you have not pushed your local changes up yet)

wip

455555e

pavelsavara added this to the 11.0.0 milestone Jan 26, 2026

pavelsavara self-assigned this Jan 26, 2026

pavelsavara added arch-wasm WebAssembly architecture area-GC-coreclr os-browser Browser variant of arch-wasm labels Jan 26, 2026

pavelsavara commented Jan 26, 2026

View reviewed changes

src/coreclr/vm/finalizerthread.cpp Outdated Show resolved Hide resolved

pavelsavara and others added 3 commits January 26, 2026 17:29

GCX_COOP, BEGIN_EXTERNAL_ENTRYPOINT, EX_TRY

4d248aa

Merge branch 'main' into browser_finalizer

a97615b

fix

74ded88

jkotas reviewed Jan 26, 2026

View reviewed changes

src/coreclr/vm/finalizerthread.cpp Outdated Show resolved Hide resolved

jkotas reviewed Jan 26, 2026

View reviewed changes

src/coreclr/vm/finalizerthread.cpp Show resolved Hide resolved

jkotas reviewed Jan 26, 2026

View reviewed changes

src/coreclr/vm/finalizerthread.cpp Outdated Show resolved Hide resolved

AaronRobinsonMSFT reviewed Jan 26, 2026

View reviewed changes

jkotas reviewed Jan 26, 2026

View reviewed changes

src/coreclr/vm/finalizerthread.cpp Show resolved Hide resolved

pavelsavara and others added 7 commits January 26, 2026 18:48

Update src/coreclr/vm/finalizerthread.cpp

ff1340e

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

Update src/coreclr/vm/finalizerthread.cpp

5d1b3fe

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

Update src/coreclr/vm/ceemain.cpp

8c843c9

Co-authored-by: Aaron R Robinson <arobins@microsoft.com>

Update src/coreclr/vm/finalizerthread.cpp

c15760c

Co-authored-by: Aaron R Robinson <arobins@microsoft.com>

Update src/coreclr/vm/finalizerthread.cpp

9d77348

Co-authored-by: Aaron R Robinson <arobins@microsoft.com>

Update src/coreclr/vm/finalizerthread.cpp

51d7483

Co-authored-by: Aaron R Robinson <arobins@microsoft.com>

Update src/coreclr/vm/finalizerthread.h

8272ca1

Co-authored-by: Aaron R Robinson <arobins@microsoft.com>

AaronRobinsonMSFT reviewed Jan 26, 2026

View reviewed changes

src/coreclr/vm/finalizerthread.cpp Show resolved Hide resolved

pavelsavara and others added 4 commits January 26, 2026 18:56

feedback

cdb1fd7

feedback

c57b7be

capture the current (single) thread as the finalizer thread

9abe1be

DisablePreemptiveGC() at the end

943a522

BrzVlad reviewed Jan 26, 2026

View reviewed changes

jkotas reviewed Jan 26, 2026

View reviewed changes

[browser][coreCLR] finalizer on a browser event loop #123629

Are you sure you want to change the base?

[browser][coreCLR] finalizer on a browser event loop #123629

Uh oh!

Conversation

pavelsavara commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-service bot commented Jan 26, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AaronRobinsonMSFT Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

pavelsavara commented Jan 26, 2026 •

edited

Loading

AaronRobinsonMSFT Jan 26, 2026 •

edited

Loading