Micro optimizations to improve the performance of EH stackwalking, particularly in the X86 with Funclets model by davidwrighton · Pull Request #114582 · dotnet/runtime

davidwrighton · 2025-04-11T23:24:52Z

Implement EHEnumInitFromStackFrameIterator as a SuppressGCTransition QCall and optimize its performance
- This allows skipping setting the InlinedCallFrame to indicate that it is an EH frame (as suppress GC transition frames are NOT generated in that situation)
- On X86 this also allows skipping using an EH prolog for this function
- Only Update the MethodRegionInfo if there are EH regions to walk
Improve the codegen and reduce the usage of UpdateRuntimeWrappedExceptions api
- Previously we would call IsRuntimeWrappedExceptions, which would lazily compute the flag. However, since we can't actually run the lazy computation during EH, we had already forced it to be initialized, so we didn't actually need to have the full lazy computation logic in place.
- Also, we were setting this flag as we walked the stack frame via SfiInit and SfiNext, but only checking it when parsing the EH clause data. Move the computation to the EHEnumInitFromStackFrameIterator api, and only compute the correct version of the flag IF there are clauses to walk.
- Only Update the IsRuntimeWrappedExceptions flag and the MethodRegionInfo if there are EH regions to walk
- For reflection emitted modules, always consider the status of this flag to be computed, but if we emit the controlling attribute, adjust the current cached computed value. NOTE: this is a minor breaking change from the previous behavior.
Improve the performance of AppendExceptionStackFrame slightly be using the variant of GCX_COOP which takes a Thread* instead of getting it from the TLS data.
Improve the performance of StackTraceInfo::AppendElement
- It always calls EnsureStackTraceArray which ALSO needs to have a protected GC variable. Instead of doing that locally in EnsureStackTraceArray, instead make the GCPROTECT in EnsureStackTraceArray be a bit larger. This allows avoiding modifying the TLS linked list of GCFrames, as well as avoids needing an x86 EH prolog for EnsureStackTraceArray
- Update ExceptionObject::GetStackTrace to use an out of line copy of code to clone the stack trace array in the presence of the multi-threaded scenario. This avoids the EH prolog on X86.
- Update ExceptionObject::GetStackTrace to avoid needing to regather the current thread, instead taking it as a parameter
- Change ExceptionObject::GetStackTraceParts to use a faster technique for checking to see if the array is an sbyte array or an object[].
Update NotifyFunctionEnter to check CORProfileTrackExceptions before calling the various profiler reporting functions. This allows the check to happen only once instead of 4 times, and also allowed me to outline some logic so that the function didn't need an EH prolog on X86
For handling of the m_emptyDebuggerExState on the ThreadExceptionState object, move that into a global static variable to improve the performance of calls of the ThreadExceptionState::GetDebuggerState api, and add a new ThreadExceptionState::SetDebuggerIndicatedFramePointer api to avoid even touching the empty debugger state
Refactor the EECodeInfo::DecodeGCHdrInfo function into a fast inlineable path, and a slow path that does a lot of work for better inlining behavior.

This PR improves the performance of deep stack EH throwing by micro-optimizing a number of scenarios. In particular in the Windows X86 Funclet model, it achieves about a 15% improvement to a simple benchmark.

…rticularly in the X86 with Funclets model - Implement EHEnumInitFromStackFrameIterator as a SuppressGCTransition QCall and optimize its performance - This allows skipping setting hte InlinedCallFrame to indicate that it is an EH frame (as suppress GC transition frames are NOT generated in that situation) - On X86 this also allows skipping using an EH prolog for this function - Only Update the MethodRegionInfo if there are EH regions to walk - Improve the codegen and reduce the usage of UpdateRuntimeWrappedExceptions api - Previously we would call IsRuntimeWrappedExceptions, which would lazily compute the flag. However, since we can't actually run the lazy computation during EH, we had already forced it to be initialized, so we didn't actually need to have the full lazy computation logic in place. - Also, we were setting this flag as we walked the stack frame via SfiInit and SfiNext, but only checkinging it when parsing the EH clause data. Move the computation to the EHEnumInitFromStackFrameIterator api, and only compute the correct version of the flag IF there are clauses to walk. - Only Update the IsRuntimeWrappedExceptions flag and the MethodRegionInfo if there are EH regions to walk - Improve the performance of AppendExceptionStackFrame slightly be using the variant of GCX_COOP which takes a Thread* instead of getting it from the TLS data. - Improve the performance of StackTraceInfo::AppendElement - It always calls EnsureStackTraceArray which ALSO needs to have a protected GC variable. Instead of doing that locally in EnsureStackTraceArray, instead make the GCPROTECT in EnsureStackTraceArray be a bit larger. This allows avoiding modifying the TLS linked list of GCFrames, as well as avoids needing an x86 EH prolog for EnsureStackTraceArray - Update ExceptionObject::GetStackTrace to use an out of line copy of code to clone the stack trace array in the presence of the multi-threaded scenario. This avoids the EH prolog on X86. - Update ExceptionObject::GetStackTrace to avoid needing to regather the current thread, instead taking it as a parameter - Change ExceptionObject::GetStackTraceParts to use a faster technique for checking to see if the array is an sbyte array or an object[]. - Update NotifyFunctionEnter to check CORProfileTrackExceptions before calling the various profiler reporting functions. This allows the check to happen only once instead of 4 times, and also allowed me to outline some logic so that the function didn't need an EH prolog on X86 - For handling of the m_emptyDebuggerExState on the ThreadExceptionState object, move that into a global static variable to improve the performance of calls of the ThreadExceptionState::GetDebuggerState api, and add a new ThreadExceptionState::SetDebuggerIndicatedFramePointer api to avoid even touching the empty debugger state - Refactor the EECodeInfo::DecodeGCHdrInfo function into a fast inlineable path, and a slow path that does a lot of work.

Copilot

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

Copilot · 2025-04-11T23:25:15Z


 class StackTraceInfo
 {
+    struct StackTraceArrayProtect


Consider adding inline documentation to clarify the roles of m_pStackTraceArray and m_pStackTraceArrayNew within StackTraceArrayProtect to improve future maintainability.

Copilot · 2025-04-11T23:25:16Z

+    }
+    CONTRACTL_END
+
+    _ASSERTE(IsRuntimeWrapExceptionsStatusComputed());


It may be helpful to document the assumption that the runtime wrap exception status is computed before calling IsRuntimeWrapExceptionsDuringEH, to aid future maintainers in understanding the precondition.

Copilot · 2025-04-11T23:25:16Z

-    GCPROTECT_BEGIN(newStackTrace);
-
-    size_t stackTraceCapacity = pStackTrace->Capacity();
+    size_t stackTraceCapacity = pStackTraceProtected->m_pStackTraceArray.Capacity();


Consider adding a comment to explain the use of m_pStackTraceArray within the StackTraceArrayProtect structure, to clarify how capacity and copying are managed in the new implementation.

jkotas

LGTM!

jkotas · 2025-04-12T00:14:47Z

 #if !defined(DACCESS_COMPILE)

 #ifdef DEBUGGING_SUPPORTED
+static DebuggerExState   m_emptyDebuggerExState;


Suggested change

static DebuggerExState m_emptyDebuggerExState;

static DebuggerExState s_emptyDebuggerExState;

jkotas · 2025-04-12T00:14:55Z

-#if defined(_MSC_VER)
-        #pragma warning(default : 4640)
-#endif
        return &m_emptyDebuggerExState;


Suggested change

return &m_emptyDebuggerExState;

return &s_emptyDebuggerExState;

AaronRobinsonMSFT · 2025-04-12T02:28:27Z

-        _ASSERTE(hdrInfoSize != 0);
-        m_hdrInfoTable = (PTR_CBYTE)gcInfoToken.Info + hdrInfoSize;
-    }
+    GCInfoToken gcInfoToken = GetGCInfoToken();


Suggested change

GCInfoToken gcInfoToken = GetGCInfoToken();

_ASSERTE(m_hdrInfoTable == NULL);

GCInfoToken gcInfoToken = GetGCInfoToken();

filipnavara · 2025-04-13T09:44:07Z

Some of the test failures look legit:

> C:\h\w\A8C60910\w\A155092C\e\baseservices\baseservices\../callconvs/TestCallingConventions/TestCallingConventions.cmd

Assert failure(PID 3332 [0x00000d04], Thread: 1432 [0x0598]): pExInfo->m_pMDToReportFunctionLeave != NULL

CORECLR! NotifyExceptionPassStarted + 0x190 (0x00007fff`a273a730)
CORECLR! SfiInit + 0x128 (0x00007fff`a273d158)
SYSTEM.PRIVATE.CORELIB! <no symbol> + 0x0 (0x00007fff`87c416d4)
SYSTEM.PRIVATE.CORELIB! <no symbol> + 0x0 (0x00007fff`87c40cc8)
CORECLR! CallDescrWorkerInternal + 0x84 (0x00007fff`a2441f94)
CORECLR! CallDescrWorkerWithHandler + 0x120 (0x00007fff`a25bc5e8)
CORECLR! DispatchCallSimple + 0xF8 (0x00007fff`a25bce28)
CORECLR! DispatchManagedException + 0x238 (0x00007fff`a27387f8)
CORECLR! IL_Throw + 0x160 (0x00007fff`a2637b30)
<no module>! <no symbol> + 0x0 (0x00007fff`42f74094)
    File: D:\a\_work\1\s\src\coreclr\vm\exceptionhandling.cpp:3680
    Image: C:\h\w\A8C60910\p\corerun.exe

I didn't try to track it down yet, but it seems related to the NotifyFunctionEnter change.

Co-authored-by: Filip Navara <filip.navara@gmail.com>

…ghton/runtime into X86FuncletPerfMicroOpts

filipnavara · 2025-04-22T15:24:34Z

Seems like the tests passed. Can we get this merged or is there still outstanding work to be done?

filipnavara · 2025-04-22T16:29:33Z

Thanks a lot!

davidwrighton · 2025-04-22T16:30:22Z

@filipnavara I'm sorry about the delay, I've been unavoidably away from work for the last week, and I'm only now getting back. I didn't get a chance to look into the debugger scenarios, so I'll try to see if I can get that done some time this week, but I may not be able to.

filipnavara · 2025-04-22T16:50:08Z

No worries. I appreciate any help with this! Thanks for keeping me in the loop.

This was caused by changes in PR dotnet#114582 where Exception::GetStackTrace called GetThread() which throws an error exception in the DAC. Changed the enummem.cpp code in ClrDataAccess::DumpManagedExcepObject() to call the GetStackTrace overload that allows a NULL pCurrentThread parameter to be passed.

) This was caused by changes in PR #114582 where Exception::GetStackTrace called GetThread() which throws an error exception in the DAC. Changed the enummem.cpp code in ClrDataAccess::DumpManagedExcepObject() to call the GetStackTrace overload that allows a NULL pCurrentThread parameter to be passed.

Copilot AI review requested due to automatic review settings April 11, 2025 23:24

ghost added the area-ExceptionHandling-coreclr only use for closed issues label Apr 11, 2025

dotnet-policy-service Bot assigned davidwrighton Apr 11, 2025

Copilot AI reviewed Apr 11, 2025

View reviewed changes

davidwrighton mentioned this pull request Apr 11, 2025

New exception handling on win-x86 #113985

Closed

6 tasks

jkotas approved these changes Apr 12, 2025

View reviewed changes

AaronRobinsonMSFT reviewed Apr 12, 2025

View reviewed changes

AaronRobinsonMSFT approved these changes Apr 12, 2025

View reviewed changes

build-analysis Bot mentioned this pull request Apr 12, 2025

LibraryImportGenerator.Unit.Tests crashing on linux-x64 mono interpreter #100800

Open

Address feedback, and fix a few of the issues found in the tests

72e890d

filipnavara approved these changes Apr 14, 2025

View reviewed changes

filipnavara reviewed Apr 14, 2025

View reviewed changes

Comment thread src/coreclr/vm/clrex.h Outdated

davidwrighton and others added 4 commits April 14, 2025 13:25

Update src/coreclr/vm/clrex.h

d899e0b

Co-authored-by: Filip Navara <filip.navara@gmail.com>

Attempt to address issue with reflection emit modules

cc6d9b5

Merge branch 'X86FuncletPerfMicroOpts' of https://github.com/davidwri…

c1f6101

…ghton/runtime into X86FuncletPerfMicroOpts

I really should be more careful about my AI generated code completion...

8548bd6

build-analysis Bot mentioned this pull request Apr 22, 2025

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

3 tasks

davidwrighton merged commit 2224669 into dotnet:main Apr 22, 2025

EgorBo mentioned this pull request Apr 24, 2025

[Perf] Linux/arm64: 10 Improvements on 4/22/2025 10:53:09 PM +00:00 dotnet/perf-autofiling-issues#54406

Closed

mikem8361 mentioned this pull request Apr 24, 2025

Fix minidump generation - missing IP for exception stack frames #115025

Merged

This was referenced Apr 29, 2025

[Perf] Windows/x64: 12 Improvements on 4/22/2025 7:20:48 PM +00:00 dotnet/perf-autofiling-issues#54646

Closed

[Perf] Linux/x64: 5 Improvements on 4/22/2025 7:20:48 PM +00:00 dotnet/perf-autofiling-issues#54595

Closed

AndyAyersMS mentioned this pull request Apr 29, 2025

[Perf] Linux/x64: 11 Improvements on 4/22/2025 7:20:48 PM +00:00 dotnet/perf-autofiling-issues#54684

Closed

davidwrighton mentioned this pull request May 8, 2025

Fix issues are stackwalking, and viewing Exception stack walks in the debugger #115405

Merged

github-actions Bot locked and limited conversation to collaborators May 23, 2025

	static DebuggerExState m_emptyDebuggerExState;
	static DebuggerExState s_emptyDebuggerExState;

	return &m_emptyDebuggerExState;
	return &s_emptyDebuggerExState;

	GCInfoToken gcInfoToken = GetGCInfoToken();
	_ASSERTE(m_hdrInfoTable == NULL);
	GCInfoToken gcInfoToken = GetGCInfoToken();

Uh oh!

Conversation

davidwrighton commented Apr 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 11, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 11, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 11, 2025

Choose a reason for hiding this comment

Uh oh!

jkotas left a comment

Choose a reason for hiding this comment

Uh oh!

jkotas Apr 12, 2025

Choose a reason for hiding this comment

Uh oh!

jkotas Apr 12, 2025

Choose a reason for hiding this comment

Uh oh!

AaronRobinsonMSFT Apr 12, 2025

Choose a reason for hiding this comment

Uh oh!

filipnavara commented Apr 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

filipnavara commented Apr 22, 2025

Uh oh!

filipnavara commented Apr 22, 2025

Uh oh!

davidwrighton commented Apr 22, 2025

Uh oh!

filipnavara commented Apr 22, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

davidwrighton commented Apr 11, 2025 •

edited

Loading

filipnavara commented Apr 13, 2025 •

edited

Loading