Skip to content

[release/7.0] Improve windows hardware exception handling performance #74590

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

janvorli
Copy link
Member

Port of #74426 to release/7.0

  • Improve windows hardware exception handling performance

With my recent change that modified hardware exception handling so that
the related managed exception is thrown directly from the vectored
exception handler, the performance of handling such exceptions have
regressed. Several exception handling dotnet/performance microbenchmarks
have regressed upto 15%.
The reason for the regression was the larger number of stack frames
between the exception raising and the actual handler frame. With a
recent change that @AntonLapounov has made to fix process corrupting
exceptions handling, the regression went down to 8%. This change moves
the location where we raise the exception down to the
ClrVectoredExceptionHandlerShim, which means to the closest possible
frame to the managed code.
This gets rid of the regression completely.

To port this to release/7.0, I also had to apply changes from #74270 to fix conflicts.

Customer Impact

Without this change, the hardware exception handling performance (exceptions occurring in tight loop) is regressed by about 8% compared to .NET 6.

Testing

CI testing, local dotnet/perf benchmarking

Risk

Low, it does not introduce functional changes, it only moves the point where the hardware exception is thrown from the vectored exception handler few layers up the call chain.

Close #71069

Port of dotnet#74426 to release/7.0

* Improve windows hardware exception handling performance

With my recent change that modified hardware exception handling so that
the related managed exception is thrown directly from the vectored
exception handler, the performance of handling such exceptions have
regressed. Several exception handling dotnet/performance microbenchmarks
have regressed upto 15%.
The reason for the regression was the larger number of stack frames
between the exception raising and the actual handler frame. With a
recent change that @AntonLapounov has made to fix process corrupting
exceptions handling, the regression went down to 8%. This change moves
the location where we raise the exception down to the
ClrVectoredExceptionHandlerShim, which means to the closest possible
frame to the managed code.
This gets rid of the regression completely.

Close dotnet#71069
@janvorli janvorli added this to the 7.0.0 milestone Aug 25, 2022
@janvorli janvorli requested a review from AntonLapounov August 25, 2022 15:55
@janvorli janvorli self-assigned this Aug 25, 2022
@janvorli janvorli requested a review from jeffschwMSFT August 25, 2022 16:39
@carlossanlop
Copy link
Contributor

@JulieLeeMSFT can we get an approval on Jeff's behalf?

@JulieLeeMSFT
Copy link
Member

@mangod9 PTAL to approve this.

@carlossanlop
Copy link
Contributor

Approved and signed off.
CI is green.
Ready to merge. :shipit:

@carlossanlop carlossanlop merged commit 5c9432e into dotnet:release/7.0 Aug 25, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Sep 25, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants