Use lock-free reads for ETW rundown versions - #132757

Backport of #132757 to release/11.0

/cc @tommcdon

## Customer Impact

- [ ] Customer reported
- [x] 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
- [x] 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.

Co-authored-by: Tom McDonald <[email protected]>
Copilot-Session: 08e6544d-6999-41a6-85b2-cbd9ea6fe071

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
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 <[email protected]>

---------

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

Backport of #132757 to release/10.0

/cc @tommcdon

## Customer Impact

- [x] 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
- [x] No

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

## Testing

- Validated the backport changes with concurrent ReJIT, revert, tiered
compilation, OSR, and repeated CLR ETW rundown cycles.
- Both Release and Debug stress runs completed with three observed ReJIT
compilations and a revert request
- Processed the generated Release and Debug ETL traces with TraceEvent,
forcing rundown events; 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.

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

Private_EventControlCallback fired on EVENT_CONTROL_CODE_ENABLE_PROVIDER
for the rundown provider and always emitted the DCEnd flavour of every
event, ignoring MatchAnyKeyword entirely. PerfView's default asks for
end rundown alone, which is what made this work by luck.

etw_rundown_pass () (etw-profiler.hpp) replaces that: a pure function of
the control code, MatchAnyKeyword and which provider fired, read against
CLR-ETW-Generated.h's own CLR_RUNDOWNSTART_KEYWORD (0x40) and
CLR_RUNDOWNEND_KEYWORD (0x100) - asserted equal to that header's values
where HOST_WIN32 makes them available, so the mirrored constants cannot
drift from the generated ones silently. 0x80 is CLR_ENDENUMERATION_KEYWORD,
a different keyword on the regular provider entirely, and is not one of
these; RundownPassIgnoresStaleKeyword gates the two are not confused.
Both keywords can be live at once, and on_attach () now runs one locked
walk that emits whichever flavour(s) each object's own pass asks for,
rather than one walk per flavour.

EVENT_CONTROL_CODE_CAPTURE_STATE is the control code a consumer sends to
ask a provider to re-emit its state without changing enablement, and ETW
hands it MatchAnyKeyword the same way it hands ENABLE_PROVIDER - the
currently-enabled keyword for that provider. So the same function answers
both, and CAPTURE_STATE on the rundown provider now gets a rundown too.

DCStartInit/DCStartComplete and DCEndInit/DCEndComplete now bracket the
walk, one pair per pass actually requested, so a consumer can tell a
finished rundown from a truncated one.

The walk still runs synchronously inside the callback, against Microsoft's
own PENABLECALLBACK advice, and that decision is argued at the
mono_unity_domain_foreach_locked () call site in on_attach (): the one
lock held for the whole walk is mono_domain_unload_mutex, which has
exactly one other call site (mono_domain_try_unload ()'s call to
mono_domain_free (), appdomain.c) and so excludes only an in-flight
domain unload - not an allocation, a JIT compile, or a thread attaching.
mono_jit_info_table_foreach_internal () itself takes no lock at all; it
reads through the same hazard pointers a concurrent publish uses. That is
a narrower hold than CoreCLR's own rundown, which dotnet/runtime#132757
found holding the code-versioning lock - one every JIT compile also takes
- for seconds on a method-heavy process, so kept synchronous.

method_jit_done () passes mono_domain_get (), and a tier-1/tier-2 publish
can run on a compile-worker thread, which attaches to the root domain.
Traced the call: MonoBackend::compile_bodies () (mono/llvm/runtime/backend.cpp)
wraps the whole publish, this raise included, in a DomainScope over the
body's own domain, so mono_domain_get () is already right by the time this
runs. Documented at the call site rather than changed.

Gtest coverage for etw_rundown_pass (): neither keyword, each alone, both
together, the regular provider, CAPTURE_STATE, DISABLE_PROVIDER, and the
0x80 confusion above. All EtwProfilerPure cases, so the existing gtest
filter in CMakeLists.txt already runs them with no registration change.

Claude-Session: https://claude.ai/code/session_01CTYKyM4Ud3ogeHAtEKXXdf