[release/7.0] Improve windows hardware exception handling performance #74590
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Port of #74426 to release/7.0
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