[release/9.0] [mono][mini] Interlocked.CompareExchange and Interlocked.Exchange intrinsics for small types and enums#106897
Merged
jeffschwMSFT merged 28 commits intorelease/9.0from Aug 26, 2024
Conversation
also add mono_atomic_cas_u8 utility function
maybe we can't actually do a 1 or 2 byte move from RAX ?
fixup u16 win32 atomic
for the 16-bit addressing prefix
…t fail to allocate a table index and generate a warning. This shouldn't happen in prod anyway Implement cmpxchg atomics natively in jiterpreter Remove unnecessary jiterp cas helpers Do cmpxchg result fixups as needed Add runtime option for jiterpreter atomics Implement atomic exchanges in the jiterpreter
github-actions
bot
requested review from
lambdageek,
lewing,
pavelsavara and
steveisok
as code owners
github-actions
bot
requested review from
BrzVlad,
fanyang-mono,
kg,
kotlarmilos and
marek-safar
as code owners
ghost
added
the
Member
jeffschwMSFT
approved these changes
Aug 23, 2024
Member
jeffschwMSFT
left a comment
jeffschwMSFT
left a comment
There was a problem hiding this comment.
approved. please get a code review. once ready we can merge
jkurdek
approved these changes
Aug 26, 2024
Contributor
jkurdek
left a comment
jkurdek
left a comment
There was a problem hiding this comment.
The arm and llvm changes look good.
|
|
||
| #define amd64_prefix_size(inst,p,size) do { x86_prefix((inst), p); } while (0) | ||
| #define amd64_rdtsc_size(inst,size) do { amd64_codegen_pre(inst); amd64_emit_rex ((inst),(size),0,0,0); x86_rdtsc(inst); amd64_codegen_post(inst); } while (0) | ||
| // FIXME: wrong for size == 1 or 2 |
Contributor
There was a problem hiding this comment.
those limitations do not concern current usage scenarios?
Member
There was a problem hiding this comment.
Correct. These macros are not currently used for size 1 or 2
Member
|
PR is green, reviewed and signed off. Ready to merge /cc @carlossanlop |
This was referenced Aug 26, 2024
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 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.
Backport of #106660 to release/9.0
/cc @lambdageek
Customer Impact
After the BCL started to use the new
Interlocked.Exchange<T>(...)andInterlocked.CompareExchange<T>(...)APIs withboolandenumtypes for certain internal lock-free data structures, Mono experienced a severe performance regression across multiple form factors because we did not implement intrinsics for types backed by 8-bit and 16-bit integers. As a result the slower IL fallbacks were used. See #105335Regression
This is a performance regression, not a correctness regression.
Testing
We have test coverage for these cases in the JIT and libraries testsuires.
Risk
Medium.
Additionally on WebAssembly we now always emit the atomic instructions in the jiterpreter. It is possible customers may deploy apps on older browser that do not implement those instructions. (Although all modern browsers support the opcodes even on non-shared memory). As a mitigation the jiterpreter includes a configuration flag to turn off JITing for traces that require the new opcodes.
It is possible that there are correctness criteria that are missed by our testsuites and we may JIT or incorrect code on some architectures. It is unlikely that we will AOT incorrect code as changes to LLVM codegen were minor. Possible customer workarounds in case of a JIT bug would be to produce AOT profiles that force AOT for the affected methods.
Fixes #105335
Fixes #93488