Repository navigation
JIT: mark GC safe point after stelem.ref call transformation - #134973
Merged
Merged
Conversation
fgMorphCall marked the block as a GC safe point while the stelem.ref call was still a user call, before it was replaced by a plain store (or converted back to a helper call). The stale flag could leave a call-free loop without GC polls. Fixes dotnet#134894 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
github-actions
Bot
added
the
area-CodeGen-coreclr
|
Azure Pipelines: Successfully started running 5 pipeline(s). 11 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
Member
Author
|
PTAL @jakobbotsch @dotnet/jit-contrib no diffs (some methods switched to fully-interruptible mode) |
jakobbotsch
approved these changes
Oct 1, 2026
EgorBo
added a commit
that referenced
this pull request
Oct 8, 2026
…135415) <!-- --> Fixes #135390 Fixes #135407 Contributes to #134837 Recent changes made more methods fully interruptible (e.g. #134973), which exposed a few pre-existing x86 GC tracking issues: - **`emitxarch.cpp`**: `emitOutputSV`/`emitOutputCV` didn't kill the GC liveness of the destination register for several formats (`*_SRD_CNS`, `*_SRD_RRD`, `*_MRD_CNS`, etc.), e.g. `rorx edi, dword ptr [ebp+0x08], 5` kept `edi` reported as a live GC ref. The address-mode path (`emitOutputAM`) already handled these. - **`codegenxarch.cpp`**: `genCodeForSwap` only passed `EA_GCREF` to the emitter when exactly one side was a GC type, so a ref<->byref `xchg` didn't swap the emitter's GC tracking (the `InvokeDirectByRefWithFewArgs` listing in #134837). Hit by the `DevDiv_*` tests that use `JitStressRegs=0x200`. - **`threadsuspend.cpp`**: on x86 the `InlinedCallFrame` stays linked for the whole method and the stack walker reports it before the containing method. `SWCB_GetExecutionState` therefore treated a thread spinning in such a method as "not in JIT code" and never redirected it, hanging GC suspension (`Runtime_134894` under GCStress). Skip the inactive `InlinedCallFrame`. Also fixed the stale "non-x86" comments in `stackwalk.cpp`. Not fixed here: an intermittent hole in the `JitNoStructPromotion=1` tests (e.g. `Runtime_71831`). `CORINFO_HELP_BULK_WRITEBARRIER_SMALL` is treated as a no-GC helper, but its first call can go through the prestub, which can GC. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Jan Kotas <jkotas@microsoft.com> Copilot-Session: a10e9000-66df-46e3-94d8-88019bcaf192
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.
fgMorphCall marked the block as a GC safe point while the stelem.ref call was still a user call, before it was replaced by a plain store (or converted back to a helper call). The stale flag could leave a call-free loop without GC polls.Fixes #134894
Diffs