JIT: fix GC holes in large stack-target struct block ops by EgorBo · Pull Request #130352 · dotnet/runtime

EgorBo · 2026-07-08T13:02:07Z

For a stack-target struct copy/zero containing GC pointers, LowerCopyBlockStore/LowerInitBlockStore correctly dropped write barriers but, above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (Memmove) / CORINFO_HELP_MEMZERO (ClearWithoutReferences) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap.

Fix:

Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path.
Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper.

The copy regression was introduced by #128542.

Verified: SPMI replay -f benchmarks.run clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms MEMCPY→BULK_WRITEBARRIER and MEMZERO→zeroing loop.

Copilot

Pull request overview

This PR updates CoreCLR JIT lowering to avoid GC-safepoint helper calls for certain large struct block operations involving GC references, preventing GC from observing partially-updated GC-reference stack (and heap) locations. It also adds a JIT regression test to exercise the affected scenarios under GCStress.

Changes:

Adjust LowerCopyBlockStore so stack-target GC-pointer struct copies only drop the CpObj path when the copy is actually unrolled into a single non-interruptible region.
Adjust LowerInitBlockStore so zeroing GC-pointer-containing structs uses the pointer-sized zeroing loop (instead of helper-based zeroing) for both stack and heap destinations.
Add a JIT regression test (Runtime_130286) and wire it into Regression_ro_2.csproj.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/coreclr/jit/lower.cpp	Changes lowering decisions for large GC-pointer block copy/zero to avoid managed helper safepoints that can expose GC holes.
src/tests/JIT/Regression/Regression_ro_2.csproj	Includes the new JitBlue regression test source file in the regression suite.
src/tests/JIT/Regression/JitBlue/Runtime_130286/Runtime_130286.cs	New regression test intended to reproduce the GC-hole scenarios (primarily under GCStress).

LowerCopyBlockStore/LowerInitBlockStore dropped write barriers for a stack destination containing GC pointers (correct) but then, for sizes above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (SpanHelpers.Memmove) / CORINFO_HELP_MEMZERO (SpanHelpers.ClearWithoutReferences) helpers. Those calls are GC-safe points, so a GC triggered mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Only take the "no write barriers" copy shortcut when the copy is actually unrolled into a single non-interruptible region; otherwise stay on the GC-aware CpObj path. Route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized zeroing loop instead of the helper. Copy regression introduced by dotnet#128542. Fixesdotnet#130286 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Fixes#130286. For a stack-target struct copy/zero containing GC pointers, `LowerCopyBlockStore`/`LowerInitBlockStore` correctly dropped write barriers but, above the unroll threshold, fell back to the managed `CORINFO_HELP_MEMCPY` (`Memmove`) / `CORINFO_HELP_MEMZERO` (`ClearWithoutReferences`) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Fix: - Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path. - Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper. The copy regression was introduced by #128542. Verified: SPMI `replay -f benchmarks.run` clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms `MEMCPY`→`BULK_WRITEBARRIER` and `MEMZERO`→zeroing loop. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

EgorBo · 2026-07-08T13:02:07Z

Fixes#130286.

For a stack-target struct copy/zero containing GC pointers, LowerCopyBlockStore/LowerInitBlockStore correctly dropped write barriers but, above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (Memmove) / CORINFO_HELP_MEMZERO (ClearWithoutReferences) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap.

Fix:

Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path.
Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper.

The copy regression was introduced by #128542.

Verified: SPMI replay -f benchmarks.run clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms MEMCPY→BULK_WRITEBARRIER and MEMZERO→zeroing loop.

Copilot

Pull request overview

This PR updates CoreCLR JIT lowering to avoid GC-safepoint helper calls for certain large struct block operations involving GC references, preventing GC from observing partially-updated GC-reference stack (and heap) locations. It also adds a JIT regression test to exercise the affected scenarios under GCStress.

Changes:

Adjust LowerCopyBlockStore so stack-target GC-pointer struct copies only drop the CpObj path when the copy is actually unrolled into a single non-interruptible region.
Adjust LowerInitBlockStore so zeroing GC-pointer-containing structs uses the pointer-sized zeroing loop (instead of helper-based zeroing) for both stack and heap destinations.
Add a JIT regression test (Runtime_130286) and wire it into Regression_ro_2.csproj.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/coreclr/jit/lower.cpp	Changes lowering decisions for large GC-pointer block copy/zero to avoid managed helper safepoints that can expose GC holes.
src/tests/JIT/Regression/Regression_ro_2.csproj	Includes the new JitBlue regression test source file in the regression suite.
src/tests/JIT/Regression/JitBlue/Runtime_130286/Runtime_130286.cs	New regression test intended to reproduce the GC-hole scenarios (primarily under GCStress).

LowerCopyBlockStore/LowerInitBlockStore dropped write barriers for a stack destination containing GC pointers (correct) but then, for sizes above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (SpanHelpers.Memmove) / CORINFO_HELP_MEMZERO (SpanHelpers.ClearWithoutReferences) helpers. Those calls are GC-safe points, so a GC triggered mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Only take the "no write barriers" copy shortcut when the copy is actually unrolled into a single non-interruptible region; otherwise stay on the GC-aware CpObj path. Route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized zeroing loop instead of the helper. Copy regression introduced by dotnet#128542. Fixesdotnet#130286 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Fixes#130286. For a stack-target struct copy/zero containing GC pointers, `LowerCopyBlockStore`/`LowerInitBlockStore` correctly dropped write barriers but, above the unroll threshold, fell back to the managed `CORINFO_HELP_MEMCPY` (`Memmove`) / `CORINFO_HELP_MEMZERO` (`ClearWithoutReferences`) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Fix: - Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path. - Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper. The copy regression was introduced by #128542. Verified: SPMI `replay -f benchmarks.run` clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms `MEMCPY`→`BULK_WRITEBARRIER` and `MEMZERO`→zeroing loop. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

EgorBo · 2026-07-08T13:02:07Z

Fixes#130286.

For a stack-target struct copy/zero containing GC pointers, LowerCopyBlockStore/LowerInitBlockStore correctly dropped write barriers but, above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (Memmove) / CORINFO_HELP_MEMZERO (ClearWithoutReferences) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap.

Fix:

Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path.
Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper.

The copy regression was introduced by #128542.

Verified: SPMI replay -f benchmarks.run clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms MEMCPY→BULK_WRITEBARRIER and MEMZERO→zeroing loop.

Copilot

Pull request overview

This PR updates CoreCLR JIT lowering to avoid GC-safepoint helper calls for certain large struct block operations involving GC references, preventing GC from observing partially-updated GC-reference stack (and heap) locations. It also adds a JIT regression test to exercise the affected scenarios under GCStress.

Changes:

Adjust LowerCopyBlockStore so stack-target GC-pointer struct copies only drop the CpObj path when the copy is actually unrolled into a single non-interruptible region.
Adjust LowerInitBlockStore so zeroing GC-pointer-containing structs uses the pointer-sized zeroing loop (instead of helper-based zeroing) for both stack and heap destinations.
Add a JIT regression test (Runtime_130286) and wire it into Regression_ro_2.csproj.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/coreclr/jit/lower.cpp	Changes lowering decisions for large GC-pointer block copy/zero to avoid managed helper safepoints that can expose GC holes.
src/tests/JIT/Regression/Regression_ro_2.csproj	Includes the new JitBlue regression test source file in the regression suite.
src/tests/JIT/Regression/JitBlue/Runtime_130286/Runtime_130286.cs	New regression test intended to reproduce the GC-hole scenarios (primarily under GCStress).

LowerCopyBlockStore/LowerInitBlockStore dropped write barriers for a stack destination containing GC pointers (correct) but then, for sizes above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (SpanHelpers.Memmove) / CORINFO_HELP_MEMZERO (SpanHelpers.ClearWithoutReferences) helpers. Those calls are GC-safe points, so a GC triggered mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Only take the "no write barriers" copy shortcut when the copy is actually unrolled into a single non-interruptible region; otherwise stay on the GC-aware CpObj path. Route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized zeroing loop instead of the helper. Copy regression introduced by dotnet#128542. Fixesdotnet#130286 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Fixes#130286. For a stack-target struct copy/zero containing GC pointers, `LowerCopyBlockStore`/`LowerInitBlockStore` correctly dropped write barriers but, above the unroll threshold, fell back to the managed `CORINFO_HELP_MEMCPY` (`Memmove`) / `CORINFO_HELP_MEMZERO` (`ClearWithoutReferences`) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Fix: - Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path. - Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper. The copy regression was introduced by #128542. Verified: SPMI `replay -f benchmarks.run` clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms `MEMCPY`→`BULK_WRITEBARRIER` and `MEMZERO`→zeroing loop. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

EgorBo · 2026-07-08T13:02:07Z

Fixes#130286.

For a stack-target struct copy/zero containing GC pointers, LowerCopyBlockStore/LowerInitBlockStore correctly dropped write barriers but, above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (Memmove) / CORINFO_HELP_MEMZERO (ClearWithoutReferences) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap.

Fix:

Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path.
Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper.

The copy regression was introduced by #128542.

Verified: SPMI replay -f benchmarks.run clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms MEMCPY→BULK_WRITEBARRIER and MEMZERO→zeroing loop.

Copilot

Pull request overview

This PR updates CoreCLR JIT lowering to avoid GC-safepoint helper calls for certain large struct block operations involving GC references, preventing GC from observing partially-updated GC-reference stack (and heap) locations. It also adds a JIT regression test to exercise the affected scenarios under GCStress.

Changes:

Adjust LowerCopyBlockStore so stack-target GC-pointer struct copies only drop the CpObj path when the copy is actually unrolled into a single non-interruptible region.
Adjust LowerInitBlockStore so zeroing GC-pointer-containing structs uses the pointer-sized zeroing loop (instead of helper-based zeroing) for both stack and heap destinations.
Add a JIT regression test (Runtime_130286) and wire it into Regression_ro_2.csproj.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/coreclr/jit/lower.cpp	Changes lowering decisions for large GC-pointer block copy/zero to avoid managed helper safepoints that can expose GC holes.
src/tests/JIT/Regression/Regression_ro_2.csproj	Includes the new JitBlue regression test source file in the regression suite.
src/tests/JIT/Regression/JitBlue/Runtime_130286/Runtime_130286.cs	New regression test intended to reproduce the GC-hole scenarios (primarily under GCStress).

LowerCopyBlockStore/LowerInitBlockStore dropped write barriers for a stack destination containing GC pointers (correct) but then, for sizes above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (SpanHelpers.Memmove) / CORINFO_HELP_MEMZERO (SpanHelpers.ClearWithoutReferences) helpers. Those calls are GC-safe points, so a GC triggered mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Only take the "no write barriers" copy shortcut when the copy is actually unrolled into a single non-interruptible region; otherwise stay on the GC-aware CpObj path. Route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized zeroing loop instead of the helper. Copy regression introduced by dotnet#128542. Fixesdotnet#130286 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Fixes#130286. For a stack-target struct copy/zero containing GC pointers, `LowerCopyBlockStore`/`LowerInitBlockStore` correctly dropped write barriers but, above the unroll threshold, fell back to the managed `CORINFO_HELP_MEMCPY` (`Memmove`) / `CORINFO_HELP_MEMZERO` (`ClearWithoutReferences`) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Fix: - Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path. - Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper. The copy regression was introduced by #128542. Verified: SPMI `replay -f benchmarks.run` clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms `MEMCPY`→`BULK_WRITEBARRIER` and `MEMZERO`→zeroing loop. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

EgorBo · 2026-07-08T13:02:07Z

Fixes#130286.

For a stack-target struct copy/zero containing GC pointers, LowerCopyBlockStore/LowerInitBlockStore correctly dropped write barriers but, above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (Memmove) / CORINFO_HELP_MEMZERO (ClearWithoutReferences) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap.

Fix:

Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path.
Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper.

The copy regression was introduced by #128542.

Verified: SPMI replay -f benchmarks.run clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms MEMCPY→BULK_WRITEBARRIER and MEMZERO→zeroing loop.

Copilot

Pull request overview

This PR updates CoreCLR JIT lowering to avoid GC-safepoint helper calls for certain large struct block operations involving GC references, preventing GC from observing partially-updated GC-reference stack (and heap) locations. It also adds a JIT regression test to exercise the affected scenarios under GCStress.

Changes:

Adjust LowerCopyBlockStore so stack-target GC-pointer struct copies only drop the CpObj path when the copy is actually unrolled into a single non-interruptible region.
Adjust LowerInitBlockStore so zeroing GC-pointer-containing structs uses the pointer-sized zeroing loop (instead of helper-based zeroing) for both stack and heap destinations.
Add a JIT regression test (Runtime_130286) and wire it into Regression_ro_2.csproj.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/coreclr/jit/lower.cpp	Changes lowering decisions for large GC-pointer block copy/zero to avoid managed helper safepoints that can expose GC holes.
src/tests/JIT/Regression/Regression_ro_2.csproj	Includes the new JitBlue regression test source file in the regression suite.
src/tests/JIT/Regression/JitBlue/Runtime_130286/Runtime_130286.cs	New regression test intended to reproduce the GC-hole scenarios (primarily under GCStress).

LowerCopyBlockStore/LowerInitBlockStore dropped write barriers for a stack destination containing GC pointers (correct) but then, for sizes above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (SpanHelpers.Memmove) / CORINFO_HELP_MEMZERO (SpanHelpers.ClearWithoutReferences) helpers. Those calls are GC-safe points, so a GC triggered mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Only take the "no write barriers" copy shortcut when the copy is actually unrolled into a single non-interruptible region; otherwise stay on the GC-aware CpObj path. Route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized zeroing loop instead of the helper. Copy regression introduced by dotnet#128542. Fixesdotnet#130286 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Fixes#130286. For a stack-target struct copy/zero containing GC pointers, `LowerCopyBlockStore`/`LowerInitBlockStore` correctly dropped write barriers but, above the unroll threshold, fell back to the managed `CORINFO_HELP_MEMCPY` (`Memmove`) / `CORINFO_HELP_MEMZERO` (`ClearWithoutReferences`) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Fix: - Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path. - Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper. The copy regression was introduced by #128542. Verified: SPMI `replay -f benchmarks.run` clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms `MEMCPY`→`BULK_WRITEBARRIER` and `MEMZERO`→zeroing loop. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

EgorBo · 2026-07-08T13:02:07Z

Fixes#130286.

For a stack-target struct copy/zero containing GC pointers, LowerCopyBlockStore/LowerInitBlockStore correctly dropped write barriers but, above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (Memmove) / CORINFO_HELP_MEMZERO (ClearWithoutReferences) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap.

Fix:

Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path.
Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper.

The copy regression was introduced by #128542.

Verified: SPMI replay -f benchmarks.run clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms MEMCPY→BULK_WRITEBARRIER and MEMZERO→zeroing loop.

Copilot

Pull request overview

This PR updates CoreCLR JIT lowering to avoid GC-safepoint helper calls for certain large struct block operations involving GC references, preventing GC from observing partially-updated GC-reference stack (and heap) locations. It also adds a JIT regression test to exercise the affected scenarios under GCStress.

Changes:

Adjust LowerCopyBlockStore so stack-target GC-pointer struct copies only drop the CpObj path when the copy is actually unrolled into a single non-interruptible region.
Adjust LowerInitBlockStore so zeroing GC-pointer-containing structs uses the pointer-sized zeroing loop (instead of helper-based zeroing) for both stack and heap destinations.
Add a JIT regression test (Runtime_130286) and wire it into Regression_ro_2.csproj.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/coreclr/jit/lower.cpp	Changes lowering decisions for large GC-pointer block copy/zero to avoid managed helper safepoints that can expose GC holes.
src/tests/JIT/Regression/Regression_ro_2.csproj	Includes the new JitBlue regression test source file in the regression suite.
src/tests/JIT/Regression/JitBlue/Runtime_130286/Runtime_130286.cs	New regression test intended to reproduce the GC-hole scenarios (primarily under GCStress).

LowerCopyBlockStore/LowerInitBlockStore dropped write barriers for a stack destination containing GC pointers (correct) but then, for sizes above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (SpanHelpers.Memmove) / CORINFO_HELP_MEMZERO (SpanHelpers.ClearWithoutReferences) helpers. Those calls are GC-safe points, so a GC triggered mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Only take the "no write barriers" copy shortcut when the copy is actually unrolled into a single non-interruptible region; otherwise stay on the GC-aware CpObj path. Route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized zeroing loop instead of the helper. Copy regression introduced by dotnet#128542. Fixesdotnet#130286 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Fixes#130286. For a stack-target struct copy/zero containing GC pointers, `LowerCopyBlockStore`/`LowerInitBlockStore` correctly dropped write barriers but, above the unroll threshold, fell back to the managed `CORINFO_HELP_MEMCPY` (`Memmove`) / `CORINFO_HELP_MEMZERO` (`ClearWithoutReferences`) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Fix: - Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path. - Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper. The copy regression was introduced by #128542. Verified: SPMI `replay -f benchmarks.run` clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms `MEMCPY`→`BULK_WRITEBARRIER` and `MEMZERO`→zeroing loop. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

EgorBo · 2026-07-08T13:02:07Z

Fixes#130286.

For a stack-target struct copy/zero containing GC pointers, LowerCopyBlockStore/LowerInitBlockStore correctly dropped write barriers but, above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (Memmove) / CORINFO_HELP_MEMZERO (ClearWithoutReferences) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap.

Fix:

Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path.
Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper.

The copy regression was introduced by #128542.

Verified: SPMI replay -f benchmarks.run clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms MEMCPY→BULK_WRITEBARRIER and MEMZERO→zeroing loop.

Copilot

Pull request overview

This PR updates CoreCLR JIT lowering to avoid GC-safepoint helper calls for certain large struct block operations involving GC references, preventing GC from observing partially-updated GC-reference stack (and heap) locations. It also adds a JIT regression test to exercise the affected scenarios under GCStress.

Changes:

Adjust LowerCopyBlockStore so stack-target GC-pointer struct copies only drop the CpObj path when the copy is actually unrolled into a single non-interruptible region.
Adjust LowerInitBlockStore so zeroing GC-pointer-containing structs uses the pointer-sized zeroing loop (instead of helper-based zeroing) for both stack and heap destinations.
Add a JIT regression test (Runtime_130286) and wire it into Regression_ro_2.csproj.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/coreclr/jit/lower.cpp	Changes lowering decisions for large GC-pointer block copy/zero to avoid managed helper safepoints that can expose GC holes.
src/tests/JIT/Regression/Regression_ro_2.csproj	Includes the new JitBlue regression test source file in the regression suite.
src/tests/JIT/Regression/JitBlue/Runtime_130286/Runtime_130286.cs	New regression test intended to reproduce the GC-hole scenarios (primarily under GCStress).

LowerCopyBlockStore/LowerInitBlockStore dropped write barriers for a stack destination containing GC pointers (correct) but then, for sizes above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (SpanHelpers.Memmove) / CORINFO_HELP_MEMZERO (SpanHelpers.ClearWithoutReferences) helpers. Those calls are GC-safe points, so a GC triggered mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Only take the "no write barriers" copy shortcut when the copy is actually unrolled into a single non-interruptible region; otherwise stay on the GC-aware CpObj path. Route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized zeroing loop instead of the helper. Copy regression introduced by dotnet#128542. Fixesdotnet#130286 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Fixes#130286. For a stack-target struct copy/zero containing GC pointers, `LowerCopyBlockStore`/`LowerInitBlockStore` correctly dropped write barriers but, above the unroll threshold, fell back to the managed `CORINFO_HELP_MEMCPY` (`Memmove`) / `CORINFO_HELP_MEMZERO` (`ClearWithoutReferences`) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Fix: - Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path. - Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper. The copy regression was introduced by #128542. Verified: SPMI `replay -f benchmarks.run` clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms `MEMCPY`→`BULK_WRITEBARRIER` and `MEMZERO`→zeroing loop. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

EgorBo · 2026-07-08T13:02:07Z

Fixes#130286.

For a stack-target struct copy/zero containing GC pointers, LowerCopyBlockStore/LowerInitBlockStore correctly dropped write barriers but, above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (Memmove) / CORINFO_HELP_MEMZERO (ClearWithoutReferences) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap.

Fix:

Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path.
Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper.

The copy regression was introduced by #128542.

Verified: SPMI replay -f benchmarks.run clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms MEMCPY→BULK_WRITEBARRIER and MEMZERO→zeroing loop.

Copilot

Pull request overview

This PR updates CoreCLR JIT lowering to avoid GC-safepoint helper calls for certain large struct block operations involving GC references, preventing GC from observing partially-updated GC-reference stack (and heap) locations. It also adds a JIT regression test to exercise the affected scenarios under GCStress.

Changes:

Adjust LowerCopyBlockStore so stack-target GC-pointer struct copies only drop the CpObj path when the copy is actually unrolled into a single non-interruptible region.
Adjust LowerInitBlockStore so zeroing GC-pointer-containing structs uses the pointer-sized zeroing loop (instead of helper-based zeroing) for both stack and heap destinations.
Add a JIT regression test (Runtime_130286) and wire it into Regression_ro_2.csproj.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/coreclr/jit/lower.cpp	Changes lowering decisions for large GC-pointer block copy/zero to avoid managed helper safepoints that can expose GC holes.
src/tests/JIT/Regression/Regression_ro_2.csproj	Includes the new JitBlue regression test source file in the regression suite.
src/tests/JIT/Regression/JitBlue/Runtime_130286/Runtime_130286.cs	New regression test intended to reproduce the GC-hole scenarios (primarily under GCStress).

LowerCopyBlockStore/LowerInitBlockStore dropped write barriers for a stack destination containing GC pointers (correct) but then, for sizes above the unroll threshold, fell back to the managed CORINFO_HELP_MEMCPY (SpanHelpers.Memmove) / CORINFO_HELP_MEMZERO (SpanHelpers.ClearWithoutReferences) helpers. Those calls are GC-safe points, so a GC triggered mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Only take the "no write barriers" copy shortcut when the copy is actually unrolled into a single non-interruptible region; otherwise stay on the GC-aware CpObj path. Route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized zeroing loop instead of the helper. Copy regression introduced by dotnet#128542. Fixesdotnet#130286 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Fixes#130286. For a stack-target struct copy/zero containing GC pointers, `LowerCopyBlockStore`/`LowerInitBlockStore` correctly dropped write barriers but, above the unroll threshold, fell back to the managed `CORINFO_HELP_MEMCPY` (`Memmove`) / `CORINFO_HELP_MEMZERO` (`ClearWithoutReferences`) helpers. Those are GC-safe points, so a GC mid-operation could observe torn GC pointers in the partially-written, GC-reported stack destination and corrupt the heap. Fix: - Copy: only take the "no write barriers" shortcut when the copy is actually unrolled (single non-interruptible region); otherwise stay on the GC-aware CpObj path. - Zero: route zeroing of any GC-pointer struct (stack or heap) to the atomic pointer-sized loop instead of the helper. The copy regression was introduced by #128542. Verified: SPMI `replay -f benchmarks.run` clean; asmdiffs limited to large GC structs now using the GC-safe path; before/after codegen confirms `MEMCPY`→`BULK_WRITEBARRIER` and `MEMZERO`→zeroing loop. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

CopilotAI review requested due to automatic review settings July 8, 2026 13:02

github-actionsBot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jul 8, 2026

Copilotstarted reviewing on behalf of EgorBo July 8, 2026 13:02 View session

CopilotAI reviewed Jul 8, 2026
View reviewed changes

Comment threadsrc/tests/JIT/Regression/JitBlue/Runtime_130286/Runtime_130286.cs
Comment threadsrc/tests/JIT/Regression/JitBlue/Runtime_130286/Runtime_130286.cs

CopilotAI review requested due to automatic review settings July 8, 2026 13:11

EgorBo force-pushed the fix-gc-hole-stack-struct-blockops branch from f930e6d to 2df526fCompare July 8, 2026 13:11

Copilotstarted reviewing on behalf of EgorBo July 8, 2026 13:11 View session

CopilotAI reviewed Jul 8, 2026
View reviewed changes

Comment threadsrc/tests/JIT/Regression/JitBlue/Runtime_130286/Runtime_130286.cs
Comment threadsrc/tests/JIT/Regression/JitBlue/Runtime_130286/Runtime_130286.cs

jakobbotsch approved these changes Jul 8, 2026
View reviewed changes

EgorBo enabled auto-merge (squash) July 8, 2026 16:59

EgorBo merged commit c6e5137 into dotnet:mainJul 8, 2026
141 of 143 checks passed

This was referenced Jul 8, 2026
slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883
Open
The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008
Open

EgorBo deleted the fix-gc-hole-stack-struct-blockops branch July 8, 2026 20:27

dotnet-maestroBot mentioned this pull request Jul 9, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#7617
Merged

dotnet-milestone-botBot added this to the 11.0-preview7 milestone Jul 10, 2026

LoopedBard3 mentioned this pull request Jul 14, 2026
[Perf] Linux/x64: 11 Regressions on 7/8/2026 10:47:18 PM +00:00 #130697
Open

github-actionsBot locked and limited conversation to collaborators Aug 10, 2026