Replace MemoryBarrier with Volatile operations in HashMap#125259
Merged
AaronRobinsonMSFT merged 1 commit intodotnet:mainfrom Mar 7, 2026
Merged
Replace MemoryBarrier with Volatile operations in HashMap#125259AaronRobinsonMSFT merged 1 commit intodotnet:mainfrom
AaronRobinsonMSFT merged 1 commit intodotnet:mainfrom
Conversation
Contributor
|
Tagging subscribers to this area: @agocke |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR replaces full MemoryBarrier() fences in hash.cpp with narrower VolatileStore (release) and VolatileLoad (acquire) operations. On ARM64, MemoryBarrier() emits a full dmb ish instruction, while stlr/ldar are cheaper one-directional fences. On x86/x64, both are compiler fences (TSO provides hardware ordering), so the change is neutral there.
Changes:
InsertValue: Plain write +MemoryBarrier()replaced withVolatileStore(release) on key publication.LookupValue/ReplaceValue/DeleteValue: Plain key comparison +MemoryBarrier()replaced withVolatileLoad(acquire) on key read.Rehash:MemoryBarrier()+ plain write replaced withVolatileStore(release) onm_rgBucketspointer update.
AaronRobinsonMSFT
force-pushed
the
hashmap-volatile-barriers
branch
from
361038d to
4fc7b9e
Compare
Replace full MemoryBarrier() fences with narrower VolatileStore (release) and VolatileLoad (acquire) operations in hash.cpp. Full fences (dmb ish on ARM64, mfence on x86) are unnecessarily expensive when only one-directional ordering is needed. - InsertValue: VolatileStore on key publication (release) ensures the value is visible before the key. - LookupValue/ReplaceValue/DeleteValue: VolatileLoad on key match (acquire) ensures subsequent value reads are ordered after the key. - ReplaceValue: VolatileStore on value update (release) ensures the new value is visible to concurrent readers. - Rehash: VolatileStore on m_rgBuckets (release) ensures new bucket contents are visible before the pointer is published. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
AaronRobinsonMSFT
force-pushed
the
hashmap-volatile-barriers
branch
from
4fc7b9e to
2c9a803
Compare
jkotas
approved these changes
Mar 6, 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
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.
Replace full
MemoryBarrier()fences with narrowerVolatileStore(release) andVolatileLoad(acquire) operations inhash.cpp. Full fences (dmb ishon ARM64,mfenceon x86) are unnecessarily expensive when only one-directional ordering is needed.Changes
VolatileStoreon key publication (release) ensures the value is visible before the key.VolatileLoadon key match (acquire) ensures subsequent value reads are ordered after the key.VolatileStoreon the key (release) to re-publish it. Readers acquire-load the key viaVolatileLoad, forming a proper release-acquire pair on the same address and ensuring they observe either the old or the fully-updated new value.VolatileStoreonm_rgBuckets(release) ensures new bucket contents are visible before the pointer is published. Readers observe these writes because they enter an EBR critical region (EbrCriticalRegionHolder::EnterCriticalRegion), which executes a fullMemoryBarrier()before readingm_rgBuckets.Impact on ARM64
dmb ish+strstlrdmb ishldarstr+dmb ishstr+stlr(key re-publish)dmb ish+strstlrOn x86/x64,
MemoryBarrier()emitsmfence(orlock or), whereasVolatileLoad/VolatileStoreare just compiler fences (TSO provides hardware ordering).