Skip to content

[release/11.0] Use acquire reads for cast cache entries - #133052

Open
github-actions[bot] wants to merge 1 commit into
release/11.0from
backport/pr-132630-to-release/11.0
Open

[release/11.0] Use acquire reads for cast cache entries#133052
github-actions[bot] wants to merge 1 commit into
release/11.0from
backport/pr-132630-to-release/11.0

Conversation

@github-actions

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

Copy link
Copy Markdown
Contributor

Backport of #132630 to release/11.0

/cc @AndyAyersMS

Customer Impact

  • Customer reported
  • Found internally

Internal customer was experiencing performance issues in this code on modern arm64 hardware on a highly concurrent server application.

Fix improves performance of their app by around 10%.

Regression

  • Yes
  • No

Testing

Verified by customer. Fix has been in main for about two weeks.

Risk

Low. No-op on xArch (with its stronger memory model).

Replace the explicit read barrier in `CastCache.TryGet` with acquire
reads of the source and target/result fields.

The lookup uses a versioned entry:

1. acquire-read the version;
2. read the source and target/result payload;
3. re-read the version and reject the entry if it changed.

The existing implementation uses ordinary loads followed by
`Volatile.ReadBarrier()`. On ARM64 this emits `dmb ishld` in the hot
cast-cache lookup path. Making the payload reads acquire operations
preserves the required ordering of the final version check without the
standalone barrier.

#### ARM64 code generation

The meothod body changes from ordinary loads plus `dmb ishld` to acquire
loads. With RCpc available, the relevant sequence is now:

```asm
ldapr   w6, [x5]       // version
ldapur  x7, [x5, #8]   // source
...
ldapur  x7, [x5, #16]  // target/result
...
ldr     w0, [x5]       // final version check
```

There is no `dmb` in the generated method. On x64, volatile reads
require no additional hardware instruction.

#### Validation

- `build.cmd -s clr -c Release -arch arm64`
- Tested on a 32 core app running on new Arm64 hw (the `dmb ishld` was a
bottleneck)

Copilot-Session: 6bd43e03-841f-47ee-80f4-4da985b32a67
@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: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant