Lazy sync of Thread::m_LastThrownObjectHandle from ExInfo::m_exception

[max-charlamb]

Note

This PR was authored with the assistance of GitHub Copilot.

Summary

Follow-up to #127300. Stop eagerly synchronizing Thread::m_LastThrownObjectHandle with ExInfo::m_exception during active exception dispatch. Instead, set LTO lazily when the ExInfo is destroyed in PopExInfos.

After #127300 made m_exception the GC-tracked exception object during dispatch, the eager LTO sync became redundant cost — every throw and dispatch transition was creating/updating a GCHandle that nothing on the dispatch path actually consumes (consumers read m_exception directly, or only need LTO once dispatch unwinds).

Key Changes

• Lazy LTO update: ExInfo::~ExInfo (via PopExInfos) writes m_exception into m_LastThrownObjectHandle exactly once, when the exception leaves the dispatch chain. m_exception remains the sole source of truth during dispatch.
• Remove SafeSetThrowables — the dual-write helper is no longer needed.
• Remove SafeUpdateLastThrownObject — eager sync sites are gone.
• Remove SyncManagedExceptionState and the InternalUnhandledExceptionFilter re-sync block.

Fold the redundant create-then-destroy in CallCatchFunclet

Previously, the simple try/throw/catch path did one wasteful GCHandle create + destroy per exception:

1. PopExInfos would SetLastThrownObject(m_exception) per popped ExInfo (creating a fresh handle each iteration).
2. CallCatchFunclet would immediately follow with if (!IsExceptionInProgress()) SetLastThrownObject(NULL) (destroying the handle just created).

PopExInfos now:

• Tracks the bottommost popped m_exception in a local OBJECTREF and writes LTO once post-loop instead of per-iteration.
• Accepts an optional clearLtoIfChainEmpties flag. When the chain becomes empty (no outer ExInfo), the catch-funclet caller passes true so the post-loop branch collapses into a single SetLastThrownObject(NULL) — itself a no-op when LTO was already NULL.

Net work for the common DispatchManagedException + simple managed catch case: zero GCHandle operations (vs one create + one destroy before). The bridging cases (search pass, second-pass unwind to native EX_CATCH, debugger interception) are unchanged: they still populate LTO with the bottommost popped m_exception so native EX_CATCH consumers can read it after the ExInfo is gone.

Cleanup of dead exception-handling helpers

While reviewing this PR, @jkotas pointed out additional dead code that the lazy-LTO change exposed, plus other latent dead code in the area:

• Merge SafeSetLastThrownObject into SetLastThrownObject — single public method, NOTHROW contract. The EX_TRY/EX_CATCH now wraps only the throwing CreateHandle call; observable behavior on the OOM fallback path is unchanged.
• Delete Thread::SetLastThrownObjectHandle — zero callers post-PR.
• Delete SetManagedUnhandledExceptionBit forward declaration — no definition existed anywhere in the codebase.
• Drop the always-NULL pThrowableIn parameter of NotifyAppDomainsOfUnhandledException.
• Replace UpdateCurrentThrowable (whose name was misleading: it never updated anything, only returned a boolean) with an inline check at the single call site using the GC-mode-agnostic IsThrowableNull / IsLastThrownObjectNull helpers.
• Delete CEEInfo::HandleException — unreachable since 2016 (4d9f4b8 "Remove SEH interactions between the JIT and the EE" replaced the old ICorJitInfo::FilterException / HandleException pair with runWithErrorTrap). The function is private, non-virtual, not part of the ICorJitInfo interface, and has zero callers in coreclr, the JIT, the AOT thunks, or SuperPMI. Removing it also retires a long-stale comment about "sync between the LTO and the exception tracker" that pre-dates the ExInfo redesign.

What stays unchanged

• m_LastThrownObjectHandle itself remains an OBJECTHANDLE — required by the ICorDebug managed debugging protocol, which reads it cross-process via BuildFromGCHandle.
• GetCurrentException / GetThreadException still prefer the live ExInfo::m_exception (via pseudo-handle) and only fall back to LTO when no ExInfo is active — same precedence as Remove ExInfo::m_hThrowable - use direct pointer for exception objects #127300.
• Preallocated-exception handling (SO, OOM) is preserved.
• The m_ltoIsUnhandled flag is kept — it is still set TRUE from EEPolicy::HandleFatalError / HandleFatalStackOverflow and consumed by the managed debugger via DAC and cDAC.

Related

• Fix stale lastThrownObjectHandle in DAC GetThreadData during active exception dispatch #127741 (by @JulieLeeMSFT) teaches the DAC's GetThreadData to consult the active ExInfo::m_exception first before falling back to Thread::m_LastThrownObjectHandle. That fix is required for SOS !PrintException / !Threads to keep returning the live exception when a debugger breaks in mid-dispatch under the lazy-LTO model in this PR.

Testing

• Ran internal diagnostics tests with no regressions

[Copilot]

Pull request overview

This PR refactors CoreCLR exception state tracking to avoid eagerly synchronizing Thread::m_LastThrownObjectHandle (LTO) with ExInfo::m_exception during active exception dispatch, instead updating LTO lazily when ExInfo entries are popped. The intent is to reduce per-throw overhead after ExInfo::m_exception became the primary GC-tracked exception object during dispatch (per #127300).

Changes:

• Update LTO lazily in ExInfo::PopExInfos from ExInfo::m_exception as each tracker is popped.
• Remove eager-sync helpers/paths (SafeSetThrowables, SafeUpdateLastThrownObject, SyncManagedExceptionState) and switch call sites to SafeSetLastThrownObject.
• Restrict direct Thread::SetLastThrownObject usage by making it private and routing external callers through SafeSetLastThrownObject (now optionally marks unhandled).

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/coreclr/vm/threads.h	Updates LTO documentation, removes eager-sync APIs, makes SetLastThrownObject private, extends SafeSetLastThrownObject signature.
src/coreclr/vm/threads.cpp	Removes SafeSetThrowables/SafeUpdateLastThrownObject implementations; updates thread teardown to clear LTO via SafeSetLastThrownObject.
src/coreclr/vm/exinfo.cpp	Adds lazy LTO update when popping ExInfo entries.
src/coreclr/vm/exceptionhandling.cpp	Removes eager LTO sync at first-chance notification and removes SyncManagedExceptionState call after catch funclets.
src/coreclr/vm/excep.cpp	Removes unhandled-exception filter resync of LTO against the active tracker.
src/coreclr/vm/eepolicy.cpp	Routes fatal error/SO paths through SafeSetLastThrownObject(..., TRUE) instead of SetLastThrownObject / SafeSetThrowables.
src/coreclr/vm/comutilnative.cpp	Uses SafeSetLastThrownObject in FailFast path.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

[jkotas]

We should do this only when it is actually going to be needed. For example, in a simple try { throw new Exception(); } catch { }, PopExInfos is going to be called from CallCatchFunclets, we create the LTO handle and the very next line in CallCatchFunclets is going to delete the LTO handle.

[jkotas]

Is this going to cause a behavior change in things like the windbg !pe command ?

Before this change, !pe issued while the thread is executing a catch block is going to print the exception that's being caught. After this change, I think it is going to print nothing.

[jkotas]

(It would be nice if we can fix this without short-lived GCHandle allocation.)

[janvorli]

@jkotas, I am not sure I understand the comment about the !pe, this code is executed after the catch funclet has returned.

[max-charlamb]

It seems like I inadvertently broke this in the last PR, Juan has #127741 that fixes this by checking m_exception before LTO.

[jkotas]

Yes, this comment is attached to a wrong line.

I think it is still valid. In main, !pe is going to print the caught exception when the program is stopped inside a catch block in main, but not anymore with this change.

[max-charlamb]

I think #127741 should cover this. !pe reads DacpThreadData.lastThrownObjectHandle. That struct value is the following after Jaun's change:

    // Prefer the active exception from ExInfo (pseudo-handle to m_exception field).
    // After the removal of SetThrowable/m_hThrowable, m_LastThrownObjectHandle is only
    // updated after exception dispatch completes, so during active dispatch it may be
    // stale.  GetThrowableAsPseudoHandle returns the address of ExInfo::m_exception
    // which has the same dereference semantics as a real GC handle.
    {
        OBJECTHANDLE ohException = thread->GetThrowableAsPseudoHandle();
        if (ohException == (OBJECTHANDLE)NULL)
        {
            ohException = thread->m_LastThrownObjectHandle;
        }
        threadData->lastThrownObjectHandle = TO_CDADDR(ohException);
    }

[max-charlamb]

There are some other cases where this logic needs to be applied. I will fix it more generally.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.

[max-charlamb]

@EgorBot -intel -amd

using BenchmarkDotNet.Attributes;
using System.Runtime.CompilerServices;

[MemoryDiagnoser]
public class ExceptionBench
{
    [Benchmark]
    public int SimpleThrowCatch()
    {
        try { throw new InvalidOperationException("x"); }
        catch (Exception e) { return e.Message.Length; }
    }

    [Benchmark]
    public int Rethrow()
    {
        try
        {
            try { throw new InvalidOperationException("x"); }
            catch { throw; }
        }
        catch (Exception e) { return e.Message.Length; }
    }

    [Benchmark]
    public int CatchAndThrowNew()
    {
        try
        {
            try { throw new InvalidOperationException("inner"); }
            catch { throw new ApplicationException("outer"); }
        }
        catch (Exception e) { return e.Message.Length; }
    }

    [Benchmark]
    public int NestedThrowCatch()
    {
        int r = 0;
        try { Outer(); }
        catch (Exception e) { r = e.Message.Length; }
        return r;
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    static void Outer()
    {
        try { Inner(); }
        catch (InvalidOperationException) { throw new ApplicationException("rewrapped"); }
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    static void Inner() => throw new InvalidOperationException("x");

    [Benchmark]
    public int DeepThrowCatch()
    {
        try { Recurse(20); return 0; }
        catch (Exception e) { return e.Message.Length; }
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    static void Recurse(int n)
    {
        if (n == 0) throw new InvalidOperationException("deep");
        Recurse(n - 1);
    }
}

The interesting cases here:

Bench	What it stresses
SimpleThrowCatch	One ExInfo lifetime — was 1 eager LTO write + 1 reset; now 1 write at PopExInfos
Rethrow	SafeUpdateLastThrownObject on rethrow — entirely removed
CatchAndThrowNew	New throw inside a catch — an extra eager LTO sync per dispatch transition
NestedThrowCatch	Multi-frame transition: previously two eager writes, now one lazy write
DeepThrowCatch	Pure unwind cost (control: shouldn't change much)

Expecting the rethrow/catch-and-throw-new paths to show the largest delta since those are the dispatch transitions where SafeUpdateLastThrownObject / SafeSetThrowables used to run.

[jkotas]

I do not think the synchronization of the LTO should depend on whether there are any trackers left on the thread. The caller should either expects the Lto to be set or not, irrespective of what other exception handling may be present upstack.

The argument may want to be called setLtoToPoppedException

[max-charlamb]

In the CallCatchFunclets case we can not set LTO inside of PopExinfos and unconditionally NULL it out afterwards. This should still prevent the extra creation in the case we care about.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.