Defer field type resolution to fix #1428 perf regression#1430
Merged
leculver merged 1 commit intomicrosoft:mainfrom Apr 28, 2026
Merged
Defer field type resolution to fix #1428 perf regression#1430leculver merged 1 commit intomicrosoft:mainfrom
leculver merged 1 commit intomicrosoft:mainfrom
Conversation
ClrField.InitData was eagerly resolving the field's type signature even when
the caller only requested Name or Attributes. The type-resolution path calls
ContainingType.GetConcreteGenericTypeArguments, which calls ClrHeap.GetTypeByName,
which performs a module-wide scan and triggers expensive mscordacwks
GetMethodTableName DAC calls. This made field-heavy workloads (e.g. enumerating
async state machines) ~10x slower than ClrMD 3.1.
Split the lazy load:
- InitData(forName) populates _name and _attributes from metadata only.
- GetClrType() / ResolveType() resolves _type from the field signature,
including the ClrGenericType + MethodTable fallback from PR microsoft#1373. Runs
only when the Type property is actually accessed.
Type-resolution state is tracked in a separate _typeInitialized field
(0 = not computed, 1 = resolved, 2 = no resolvable type) so the _attributes
sentinel no longer doubles as a type-resolution flag, and so deterministically
failed resolutions don't retry on every Type access.
No locks or Interlocked are used on the type-resolution path. Reads and writes
of int and reference are atomic in .NET, and the result is deterministic for
a given field, so racing threads always agree. GetClrType() re-reads _type
after _typeInitialized and recomputes if it sees _typeInitialized == 1 with
a null _type, which tolerates write-write reordering on weakly-ordered
architectures (ARM).
Add regression tests verifying that reading Name (or Attributes) before Type
still produces the correct concrete generic instantiation.
max-charlamb
approved these changes
Apr 28, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
ClrField.InitData was eagerly resolving the field's type signature even when the caller only requested Name or Attributes. The type-resolution path calls ContainingType.GetConcreteGenericTypeArguments, which calls ClrHeap.GetTypeByName, which performs a module-wide scan and triggers expensive mscordacwks GetMethodTableName DAC calls. This made field-heavy workloads (e.g. enumerating async state machines) ~10x slower than ClrMD 3.1.
Split the lazy load:
Type-resolution state is tracked in a separate _typeInitialized field (0 = not computed, 1 = resolved, 2 = no resolvable type) so the _attributes sentinel no longer doubles as a type-resolution flag, and so deterministically failed resolutions don't retry on every Type access.
No locks or Interlocked are used on the type-resolution path. Reads and writes of int and reference are atomic in .NET, and the result is deterministic for a given field, so racing threads always agree. GetClrType() re-reads _type after _typeInitialized and recomputes if it sees _typeInitialized == 1 with a null _type, which tolerates write-write reordering on weakly-ordered architectures (ARM).
I also made this change adding a field because of the current alignment of ClrField. Adding this int is free since padding is added already (even on 32bit), this just eats the hidden padding. I'd pursue a different fix if that wasn't the case.
Add regression tests verifying that reading Name (or Attributes) before Type still produces the correct concrete generic instantiation.
Fixes #1428.