Thread contention while throwing and catching exceptions

[rchoffardet]

Description

I don't know if that's expected. Feel free to close the issue if it is.

We identified some thread contention while throwing and catching exceptions on multiple threads.
The methodology was to simply throw 10_000 exceptions in a multithreaded context. I was expecting that the CPU time spent per exception would stay relatively stable but it's increasing instead. If you do the same thing with method calls, the CPU time per calls stays flat.

Configuration

Windows 11 (10.0.22631.3007/23H2/2023Update/SunValley3)
12th Gen Intel Core i7-12700H, 1 CPU, 20 logical and 14 physical cores
.NET 8.0.0 (8.0.23.53103), X64 RyuJIT AVX2

Regression?

I don't know

Data

Code

https://gist.github.com/rchoffardet/228f4bf1892e403c65487fcfe46afe35

Result

[ghost]

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

Issue Details

---

Description

I don't know if that's expected. Feel free to close the issue if it is.

We identified some thread contention while throwing and catching exceptions on multiple threads.
The methodology was to simply throw 10_000 exceptions in a multithreaded context. I was expecting that the CPU time spent per exception would stay relatively stable but it's increasing instead. If you do the same thing with method calls, the CPU time per calls stays flat.

Configuration

Windows 11 (10.0.22631.3007/23H2/2023Update/SunValley3)
12th Gen Intel Core i7-12700H, 1 CPU, 20 logical and 14 physical cores
.NET 8.0.0 (8.0.23.53103), X64 RyuJIT AVX2

Regression?

I don't know

Data

Code

https://gist.github.com/rchoffardet/228f4bf1892e403c65487fcfe46afe35

Result

Author:	rchoffardet
Assignees:	-
Labels:	area-System.Threading, tenet-performance, untriaged
Milestone:	-

[janvorli]

@rchoffardet thank you for the test and reported issue! There is a global lock in the exception stack trace building, maybe that's the source of the contention identified by the attached test. It is something I am planning to get rid of. I'll run the test locally to get full understanding of where the issue is.

[rchoffardet]

Along my tests, I noticed that when I retrieve the stack trace, it takes more time and it allocates more, so I naively thought that the stack trace wouldn't be build if not requested. Maybe that's related to the string building and not the stack trace itself.