Implement cDAC TraverseLoaderHeap via Loader contract

[Copilot]

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

docs/design/datacontracts/GC.md:118

• GC.md no longer documents several APIs that are still part of the IGC contract (e.g., GetHandleExtraInfo, GetHandleTableMemoryRegions/GetGCBookkeepingMemoryRegions/GetGCFreeRegions), nor their associated data descriptors/globals/pseudocode. This looks like an accidental deletion during the intended reordering; please restore/move those sections so the doc matches the current IGC interface surface.

    // Gets the supported handle types
    HandleType[] GetSupportedHandleTypes();
    // Converts integer types into HandleType enum
    HandleType[] GetHandleTypes(uint[] types);
    // Gets the extra info (user data) associated with a dependent handle
    TargetNUInt GetHandleExtraInfo(TargetPointer handle);

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated 1 comment.

[max-charlamb]

lgtm mod couple of suggestions

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated 1 comment.

[github-actions]

🤖 Copilot Code Review — PR #125129

Note

This review was generated by GitHub Copilot.

Holistic Assessment

Motivation: This PR simplifies the ILoader contract by consolidating three per-field accessor methods into a single GetLoaderHeapBlockData method and deduplicates the TraverseLoaderHeap implementation shared between ISOSDacInterface and ISOSDacInterface13. The motivation is sound — the three methods always read from the same cached LoaderHeapBlock object, making separate accessors unnecessary overhead, and the two TraverseLoaderHeap bodies were exact copies.

Approach: The approach is clean and minimal. A new LoaderHeapBlockData readonly struct bundles the three fields, the Loader_1 implementation reads the cached Data.LoaderHeapBlock once (previously GetOrAdd was called three times per block — though subsequent calls returned the cached instance), and the private TraverseLoaderHeapCore helper correctly extracts the shared traversal logic. The #if DEBUG verification code correctly remains in each interface method since they verify against different legacy implementations (_legacyImpl vs _legacyImpl13).

Summary: ✅ LGTM. The refactoring is behavior-preserving, well-tested, and improves the codebase by reducing duplication and interface surface. No correctness, safety, or performance concerns.

---

Detailed Findings

✅ Correctness — Behavior is preserved

Verified that Data.LoaderHeapBlock's constructor (LoaderHeapBlock.cs:11-18) reads all three fields (Next, VirtualAddress, VirtualSize) atomically during construction, and ProcessedData.GetOrAdd caches the result. This means the old three-method pattern (GetLoaderHeapBlockAddress → GetLoaderHeapBlockSize → callback → GetNextLoaderHeapBlock) was already reading all fields in the first call. The consolidated GetLoaderHeapBlockData has identical read-failure semantics — there is no scenario where one field could fail independently.

The ISOSDacInterface13.TraverseLoaderHeap's kind parameter is not used in the core traversal logic. This was also the case before the refactoring (confirmed by examining the pre-PR code). The parameter is still correctly forwarded in the #if DEBUG verification path to _legacyImpl13.TraverseLoaderHeap.

✅ Code Deduplication — TraverseLoaderHeapCore extraction is correct

The TraverseLoaderHeapCore method contains exactly the shared logic that was duplicated. The #if DEBUG validation blocks remain correctly split between the two callers since they verify against different legacy interface implementations. The thread-static debug state (_debugTraverseLoaderHeapBlocks, _debugTraverseLoaderDebugCount) is cleared at the start of TraverseLoaderHeapCore and read after return in each caller — this is safe because the flow is sequential within a single call.

✅ API Design — LoaderHeapBlockData is appropriate

The readonly struct with init properties is a reasonable choice. The neighboring ModuleLookupTables type uses record struct, so either pattern is acceptable in this codebase. The struct is small (two pointers + one nuint) and value-typed, which is correct for a return-by-value diagnostic data object.

✅ Test Quality — Tests are adequate and follow conventions

• All three test scenarios (empty, single-block, multi-block) are updated
• The version: 1 → version: "c1" fix aligns the test with the convention used in all other cDAC tests (confirmed across LoaderTests.cs, GCTests.cs, ThreadTests.cs, etc.)
• var usage for new expressions follows the .editorconfig convention

✅ Documentation — Loader.md updates are consistent

• The LoaderHeapBlockData struct and consolidated GetLoaderHeapBlockData method are properly documented in the data contract specification
• The Webcil data descriptor table entries (WebcilHeader, WebcilSectionHeader) were removed correctly — these types do not exist in datadescriptor.inc and the entries were stale documentation. The Webcil pseudocode elsewhere in the document remains intact

💡 Minor — PR description is empty

The PR body contains only the Copilot boilerplate. A brief description of the consolidation rationale would help future readers, but this is not blocking.

---

Models contributing to this review: claude-opus-4.6 (primary), gpt-5.3-codex, claude-haiku-4.5. All models agreed on correctness; one false positive (read-failure behavior change) was investigated and dismissed after verifying the LoaderHeapBlock constructor reads all fields atomically.

Generated by Code Review for issue #125129 · ◷