[cdac] Cache LayoutSet resolution in generated IData constructors

[max-charlamb]

Note

This PR description was drafted with assistance from GitHub Copilot CLI; the changes themselves were co-authored interactively with the author.

Summary

Caches the result of LayoutSet.Resolve(target, _typeNames) so each cdac-generated IData<T> constructor reuses its per-(target, typeNames) layout rather than rebuilding it. On a 1M-object heap walk this drops Data.Array construction allocations by ~88% and wall time by 17–36% depending on call site.

Why

The cdac source generator emits, for every IData<T> class, a constructor body like:

public Array(Target target, TargetPointer address)
{
    Address = address;
    LayoutSet layouts = LayoutSet.Resolve(target, _typeNames);   // <-- alloc-heavy
    layouts.Select(address, out var t, out var b, out var n, "m_NumComponents");
    NumComponents = target.ReadField<uint>(b, t, n);
    OnInit(target, address);
}

LayoutSet.Resolve allocates a List<LazyLayout> and a backing array on every call, but the result is a pure function of (Target, _typeNames). Both inputs are stable for the lifetime of a target snapshot — _typeNames is a static array the generator emits once per data class. So the result can (and should) be cached.

How

The cache is stored on a target-agnostic contract — IGeneratedTypeCache — emitted by the cdac source generator alongside LayoutSet and TypeNameResolver:

internal interface IGeneratedTypeCache : IContract
{
    LayoutSet GetOrAddLayoutSet(string[] typeNames);
}

GeneratedTypeCache_1 is the implementation: a Dictionary<string[], LayoutSet> with ReferenceEqualityComparer (the generator emits string[] literals once per data class, so reference equality is the correct comparer and gives 100% hit rate after the first instantiation).

A TargetExtensions.GetCachedLayoutSet extension method (also generator-emitted) lazily registers IGeneratedTypeCache on first use, so generated code can call target.GetCachedLayoutSet(_typeNames) without any explicit registration step in the host.

The Emitter is updated to emit _target.GetCachedLayoutSet(_typeNames) in place of LayoutSet.Resolve(_target, _typeNames). LayoutSet is also changed from readonly struct to sealed class so cached entries are shared by reference rather than copied on every Dictionary lookup and method dispatch.

Empty-version registration special-case

IGeneratedTypeCache is a host-side contract — it has no target-side data and is not advertised by the target's contract descriptor. To wire it into the existing ContractRegistry.Register(version, creator) API without adding a new method, this PR establishes a convention:

• Register("", creator) — registers an implementation under the empty-string version.
• In TryGetContract, when the target does not advertise a version for the contract, the registry falls back to the empty-string registration if any is present.
• When the target does advertise a version, the registry still requires an exact-version match and fails if no implementation is registered for that version — fallback does not kick in (preserves version-skew detection).

This lets the source generator hook the cache contract into the existing registry without a new abstract API.

Benchmark

1M small-string heap walk, three implementations of Object.GetSize's m_NumComponents read, medians of 10 iterations (standalone HeapWalkBench harness, not part of this PR):

Variant	ms before	ms after	Δ ms	KB before	KB after	Δ KB
CachedIData (ProcessedData.GetOrAdd<Data.Array>)	724	461	-36%	364,571	43,545	-88%
UncachedIData (new Data.Array(...))	338	281	-17%	364,571	43,532	-88%
RawRead (target.Read<uint>(addr + offset))	174	175	unchanged (control)	4,536	4,389	unchanged (control)

The RawRead control variant doesn't go through any IData ctor so it shouldn't move — and doesn't.

Stacked with #129345's LinearReadCache scope API, the UncachedIData variant drops further to 226 ms / 4,389 KB — matching RawRead's allocation profile entirely, because JIT escape analysis is then able to stack-allocate the per-object Data.Array instances (the LinearReadCache makes the read path a direct call instead of an opaque delegate).

Tests

All 2,605 cdac unit + DataGenerator tests pass on a clean rebuild. Both ContractRegistry test stubs (TestPlaceholderTarget, DataGenerator/TestTarget) are updated to honor the empty-version fallback rule.

Out of scope / follow-ups

• Caching the resolved IGeneratedTypeCache reference per-Target in a fast-access slot would eliminate the remaining ~14% TryGetContract cost per IData ctor (per profile data). Deferred — broader Target-level implications.
• Per-field caching inside LayoutSet measured at ~3% additional wall-time win. Deferred — small enough to live in its own PR with its own measurement story.
• A standalone perf-regression bench tool (HeapWalkBench + GcStressHeap debuggee) was developed for this work but is not included; happy to submit separately if useful.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR updates the cdac source generator and contract registry behavior to enable caching of LayoutSet.Resolve(target, _typeNames) results per target, reducing repeated allocations during high-volume IData<T> construction. It does so by introducing a generator-emitted host-internal contract + extension helper and by teaching registries (and test stubs) to fall back to an empty-string “default” registration when a contract version isn’t advertised.

Changes:

• Add a generator-emitted IGeneratedType contract + TargetExtensions.GetCachedLayoutSet(...) helper to cache resolved LayoutSet instances keyed by the generated _typeNames arrays.
• Change generated code emission to use GetCachedLayoutSet instead of calling LayoutSet.Resolve directly; make LayoutSet a sealed class to support reference sharing.
• Update CachingContractRegistry and test registries to support empty-string fallback contract resolution behavior.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/native/managed/cdac/tests/TestInfrastructure/TestPlaceholderTarget.cs	Updates test contract registry to support empty-string fallback resolution.
src/native/managed/cdac/tests/DataGenerator/TestTarget.cs	Enhances generator test target’s contract registry to support registrations, caching, and fallback behavior.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader/CachingContractRegistry.cs	Implements empty-string fallback behavior in the production registry’s contract resolution.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Abstractions/ContractRegistry.cs	Documents the empty-string “default” registration and fallback semantics.
src/native/managed/cdac/gen/LayoutSetSource.cs	Changes emitted LayoutSet from readonly struct to sealed class.
src/native/managed/cdac/gen/GeneratedTypeContractSource.cs	Adds generator source for IGeneratedType, GeneratedType_1, and TargetExtensions.GetCachedLayoutSet.
src/native/managed/cdac/gen/Emitter.cs	Switches generated IData<T> codegen to use cached layout sets.
src/native/managed/cdac/gen/CdacGenerator.cs	Gates and emits the new helper contract source when not already accessible.

[rcj1]

Caching layouts upon LayoutSet.Resolve is fine as an implementation detail, but I do not see why this needs to be a contract.

[max-charlamb]

Caching layouts upon LayoutSet.Resolve is fine as an implementation detail, but I do not see why this needs to be a contract.

Contracts are the way the target maintains state. Without making a contract here, we'd need a special hook on the Target interface to manage the lifecycle of the cache. The contract is not exposed publicly and is really just an implementation detail of the datagenerator.

[rcj1]

Contracts are the way the target maintains state

We have a DataCache on the target. Is that not state?

[max-charlamb]

Contracts are the way the target maintains state

We have a DataCache on the target. Is that not state?

    /// <summary>
    /// Holds a snapshot of the target's structured data
    /// </summary>
    public interface IDataCache
    {
        /// <summary>
        /// Read a value from the target and cache it, or return the currently cached value
        /// </summary>
        /// <typeparam name="T">The type  of data to be read</typeparam>
        /// <param name="address">The address in the target where the data resides</param>
        /// <returns>The value that has been read from the target</returns>
        T GetOrAdd<T>(TargetPointer address) where T : Data.IData<T>;
        /// <summary>
        /// Return the cached value for the given address, or null if no value is cached
        /// </summary>
        /// <typeparam name="T">The type of the data to be read</typeparam>
        /// <param name="address">The address in the target where the data resides</param>
        /// <param name="data">On return, set to the cached data value, or null if the data hasn't been cached yet.</param>
        /// <returns>True if a copy of the data is cached, or false otherwise</returns>
        bool TryGet<T>(ulong address, [NotNullWhen(true)] out T? data);
        /// <summary>
        /// Clear all cached data
        /// </summary>
        void Clear();
    }

The IDataCache is specifically for IData types. The alternative would be some general-purpose caching infrastructure that allows each user customizability of how and when things are cached. That would be pretty similar to the contract system today.

[rcj1]

The IDataCache is specifically for IData types.

I am very much aware of this. I see no reason why you couldn’t add another cache specifically for layouts. It would not claim to be a contract, a general-purpose caching system, or anything else other than a cache for layouts.

We have a IDataCache for IData types, and plan to have a ReadCache for memory. Neither of them needs to be part of a general-purpose caching system, because we know they have different functions and different needs. This is no different.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.

[max-charlamb]

The IDataCache is specifically for IData types.

I am very much aware of this. I see no reason why you couldn’t add another cache specifically for layouts.

I don't want to change the Target interface for an implementation detail of the datagenerator which may change in the future (I was looking at caching individual field offsets for hot paths but found the perf difference is minimal).

Is there a reason you don't like using an internal contract for this purpose?

[rcj1]

I don't want to change the Target interface

Could this be an implementation detail of LayoutSet instead?

[rcj1]

Is there a reason you don't like using an internal contract

Contracts are supposed to give us information about a specific area of the runtime. This “contract” is just an implementation detail of the cDAC itself. Yes it is internal, but it is still stretching the intended use.

[noahfalk]

This feels like we are straining the IContract concept. All our other contracts have a 1:1 correspondence with data contracts and we create them based on versioned implementations. This one feels more like we wanted a component with Target lifetime and a Flush() callback and contracts provide those two capabilities.

I'm OK with it as pragmatically I'm not seeing it cause an issue, but in the future if the contract concept pulls away from this further we might need to do some refactoring.