Walk compressed IL -> Native map for EventTrace and stacktrace symbolication scenarios #116031
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- This removes it from normal path - This also adds an assert that it is correct Logically, this code should probably replace the current implementation of GetILOffsetFromNative but this first pass is just to get the code working This is untested, but it does compile.
3 tasks
3 tasks
… chunks and doing very cheap operations per nibble read - Add a fixed size cache around the native to IL mapping operations in the stacktrace logic - Unfortunately, simply reading the nibble data is pretty slow, so this is needed to avoid regressing performance - With this change the performance of newing up a StackTrace object on a multithreaded environment is primarily driven by GC allocation rate, and not significantly by any other locks.
This was referenced May 29, 2025
Open
This was referenced Jun 18, 2025
This both generates less data (Experiments show about a 70KB reduction in size of System.Private.CoreLib.dll R2R image) And the reader as implemented here, is quite a bit faster When combined with the cache constructed in a different part of this PR, this results in the cost of IL offset determination for a given IP to have negligible cost.
jkotas
reviewed
Jun 23, 2025
- Add handling for event tracing uses of IL to Native mapping logic to avoid using the diagnostic infrastructure there - Add validation logic for the event tracing path the ValidateILOffsets - Limit the NativeOffset to IL Offset validation logic to do O(N) work instead of O(N*N) work in worst case.
…ng a template instead of 2 seperate implementations
davidwrighton
changed the title
davidwrighton
requested review from
MichalStrehovsky,
BrzVlad,
janvorli and
kg
as code owners
… we'll only use a portion of it
noahfalk
reviewed
Jul 9, 2025
|
fyi @dotnet/dotnet-diag |
….com/davidwrighton/runtime into UseWalkILOffsetInsteadOfDebuggerData
This was referenced Jul 9, 2025
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Add paths for reading the IL-Native map which doesn't create a DebuggerFunctionInfo or DebuggerJitInfo
Use it in the stackwalker code for EH, and for the event tracing MethodToILMap
This process is somewhat slower than the path through the diagnostic infrastructure, but it has no expensive locks required. To mitigate the performance loss, the format of the compressed bounds information was changed to a an encoding where all entries in the table are fixed size, but the actual bit widths of the various fields are optimally small. Overall this results in a size savings of about 50KB on System.Private.CoreLib.dll, as well as capturing back all of the performance costs of this change for relatively small functions.
In combination with the NativeToIL map cache added a few days ago, this allows us to eliminate locks from the native offset to il offset path, which should substantially reduce the cost when heavily multithreaded applications are experiencing significant error rates. (And the cache added mitigates the remaining performance loss from using the compressed data instead of the uncompressed form.)
In addition, by changing the event trace path to use the same approach, we will remove the
DebuggerJitInfogeneration path from most customers non-debugging scenarios. (It still remains in the ICorProfiler:GetILToNativeMapping apis, but usage of that api is relatively rare).There is validation which utilizes the debugger apis to validate that the behavior hasn't changed at all.