Skip to content

[release/11.0] Use lock-free reads for ETW rundown versions - #133043

Merged
steveisok merged 1 commit into
release/11.0from
backport/pr-132757-to-release/11.0
Sep 2, 2026
Merged

[release/11.0] Use lock-free reads for ETW rundown versions#133043
steveisok merged 1 commit into
release/11.0from
backport/pr-132757-to-release/11.0

Conversation

@github-actions

@github-actions github-actions Bot commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Backport of #132757 to release/11.0

/cc @tommcdon

Customer Impact

  • Customer reported
  • Found internally

Reported by an internal partner team. Applications with large numbers of JIT-compiled methods can spend several seconds performing ETW rundown while holding the global code-versioning lock. JIT paths that need the same lock can be delayed for the duration of rundown, blocking code execution.

Regression

  • Yes
  • No

No. This fixes longstanding lock contention in the ETW rundown implementation.

Testing

  • Validated with concurrent ReJIT, revert, tiered compilation, OSR, and repeated CLR ETW rundown cycles.
  • Validated both Release and Debug CoreCLR configurations without assertions or access violations.
  • Processed generated ETL traces programmatically with TraceEvent, forcing payload materialization for every CLR rundown event; no malformed payloads or decoding errors were found.

Risk

  • Low
  • Diagnostics only. The primary behavioral tradeoff is that we might not report a method that is in-progress of being JIT'd during rundown. This is acceptable because rundown does not guarantee a globally atomic snapshot.

The current ETW rundown code holds a `CodeVersionManager` lock across
the full JIT method enumeration and ETW event emission. This can block
JIT paths and delay code execution.

This code change removes rundown-wide `CodeVersionManager` lock and
instead relies on lock-free reads of published native-code version
state. It builds on PR
#[102298](#102298) and PR
#[107152](#107152), which
established published version state and lock-free read-only version
lookups. It is noteworthy that a concurrent ReJIT or tiering update may
cause rundown to skip over a newly inserted node or skip a record when
code-address validation fails (if it is in the middle of an update). The
benefit of a `CodeVersionManager` lock-free rundown likely outweighs
guaranteeing a globally atomic rundown snapshot.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Copilot-Session: 08e6544d-6999-41a6-85b2-cbd9ea6fe071
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

@dotnet-policy-service

Copy link
Copy Markdown
Contributor

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

@steveisok steveisok added the Servicing-approved Approved for servicing release label Sep 1, 2026
@steveisok

Copy link
Copy Markdown
Member

/ba-g Known helix job monitor issue.

@steveisok
steveisok merged commit f9825c7 into release/11.0 Sep 2, 2026
120 of 127 checks passed
@steveisok
steveisok deleted the backport/pr-132757-to-release/11.0 branch September 2, 2026 02:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants