[Perf] Linux/arm64: 1 Regression on 6/16/2026 12:54:32 AM +00:00

[performanceautofiler]

Run Information

Name	Value
Architecture	arm64
OS	ubuntu 22.04
Queue	AmpereUbuntu
Baseline	98bfa17c9f3910eec30099b7ac140d8a09df6227
Compare	98d5787a726f050c592e7c126c6ab62b1954288c
Diff	Diff
Configs	CompilationMode:tiered, RunKind:micro

Regressions in PerfLabTests.LowLevelPerf

Benchmark	Baseline	Test	Test/Base	Test Quality	Edge Detector	Baseline IR	Compare IR	IR Ratio
TypeReflectionObjectGetType - Duration of single invocation 📝 - Benchmark Source ADX - Test Multi Config Graph	33.45 μs	44.60 μs	1.33	0.00	False

Test Report

Repro

General Docs link: https://github.com/dotnet/performance/blob/main/docs/benchmarking-workflow-dotnet-runtime.md

git clone https://github.com/dotnet/performance.git
python3 .\performance\scripts\benchmarks_ci.py -f net8.0 --filter 'PerfLabTests.LowLevelPerf*'

Details

PerfLabTests.LowLevelPerf.TypeReflectionObjectGetType

ETL Files

Histogram

JIT Disasms

Docs

Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository

[LoopedBard3]

🔍 Automated Triage Analysis

Summary: Verified regression in TypeReflectionObjectGetType — caused by commit d04703b ("Don't give up on folding obj.GetType if obj can be null (#129371)").

Finding Confidence: 5/5 (analysis accuracy)
Regression Confidence: 5/5 (likelihood of true regression)

Likely Cause: d04703b52beb11e1385af3f766f605af0949db72

🤖 Proposed Next Actions: Known-cause regression — transfer & notify — 4 proposed (rule R4_known_regression_new — see Full Analysis for the table).

📊 Full Analysis (click to expand)

Summary: Clear regression in PerfLabTests.LowLevelPerf.TypeReflectionObjectGetType (+33.3%) attributed to commit d04703b ("Don't give up on folding obj.GetType if obj can be null"). Finding confidence 4/5 (298 historical runs, ultra-stable CV=0.055%, z=607.49), regression confidence 5/5 (surgical JIT change directly targeting obj.GetType() folding, extreme step change, committed at exact regression timestamp). The commit alters JIT value-numbering behavior for GetType() calls on possibly-null references, which changes the generated code path on arm64.

Issue Overview

• Issue: [Perf] Linux/arm64: 1 Regression on 6/16/2026 12:54:32 AM +00:00 #129585 - [Perf] Linux/arm64: 1 Regression on 6/16/2026 12:54:32 AM +00:00
• Date: 2026-06-16 | Queue: Ubuntu.2204.Arm64.Perf | OS/Arch: linux/arm64
• Commits: 98bfa17c9f39 → 98d5787a726f (21 commits)
• Labels: untriaged, ampere, perf-regression, os-linux, arch-arm64, runtime-coreclr, kind-micro, compilationmode-tiered, runkind-micro
• Historical Data: Available (298 prior runs, 5 after runs)
• Runtime stack: Desktop + CoreCLR (implicit)

Test Analysis

Test Name	Baseline	Compare	Δ%	μ	σ	n	z	Thresh%	Noise?	Assessment
PerfLabTests.LowLevelPerf.TypeReflectionObjectGetType	33.45 μs	44.60 μs	+33.33%	33454.4	18.3	298	607.49	5%	N	Extreme step change, ultra-stable history (CV=0.055%)

Legend: μ=mean (ns), σ=stddev (ns), n=prior runs, z=z-score, Thresh%=adaptive threshold

Finding Confidence: 4/5 - Excellent historical data (298 runs, CV=0.055%), ultra-stable baseline with near-perfect measurement stability. All 5 after-values cluster tightly at ~44590ns confirming reproducibility.

Candidate Stack Relevance

Commit	Touched Paths (summary)	Relevance	Notes
d04703b52beb	src/coreclr/jit/gentree.cpp, src/coreclr/jit/valuenum.cpp	Relevant	JIT VN change for obj.GetType() folding — directly exercises CoreCLR JIT
00803896e74e	src/coreclr/vm/object.h, Delegate.CoreCLR.cs, readytorun.h	Relevant	Delegate layout reordering + R2R version bump; CoreCLR runtime change
36812f06f261	JIT R2R direct-call target loads	Relevant	JIT change but targets R2R call loads, not GetType
07b0630df574	JIT RangeOps::Merge	Relevant	JIT optimization pass, unlikely to affect GetType
ca65f7d507cc	src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs	Relevant	NativeAOT debug handle changes; no impact on CoreCLR JIT codegen

Confirmed Regressions

PerfLabTests.LowLevelPerf.TypeReflectionObjectGetType (+33.3%)

• Delta: 33.45 μs → 44.60 μs (+33.33%)
• Historical Context: μ=33454.4ns (σ=18.3ns, n=298); z-score=607.49; adaptive threshold=5%
• Assessment: Extreme step change. Historically ultra-stable with CV=0.055%. All 5 post-regression runs cluster tightly at ~44590ns (range <24ns), ruling out measurement noise. The z-score of 607.49 is extraordinarily high.
• Finding Confidence: 4/5 - Excellent data quality with 298 prior runs and near-zero variance. Not yet verified via RunWithBuildAtHash.
• Regression Confidence: 5/5 - Surgical JIT change directly targeting obj.GetType() folding logic, extreme outlier (z=607.49), and the commit timestamp (2026-06-16T00:54:09) aligns precisely with the regression date (2026-06-16T00:54:32).
• Benchmark Source: LowLevelPerf.cs#L402-L411 — calls stringField.GetType() in a tight loop where stringField is a string field initialized in GlobalSetup.
• Likely Cause: d04703b52beb - "Don't give up on folding obj.GetType if obj can be null (Don't give up on folding obj.GetType if obj can be null #129371)"
  • Affected Areas: JIT / Value Numbering / GetType folding
  • Stack Relevance: Relevant
  • Rationale: This commit changes the JIT's value-numbering pass to fold obj.GetType() into a constant type handle even when the object reference may be null, while preserving a NullReferenceException check in the exception set. In the benchmark, stringField is an instance field that the JIT may conservatively treat as potentially null. Before this change, the JIT would call the GetType() method directly. After this change, the folding now produces a constant load with a null check, which on arm64 appears to be slower — possibly due to changes in loop code shape, branch prediction characteristics, or the additional exception-set handling altering the generated instruction sequence. The commit was authored at exactly the same timestamp as the regression date, providing precise temporal alignment.
  • Candidates Considered:
    • d04703b52beb - Direct match: modifies obj.GetType() folding in JIT VN pass
    • 00803896e74e - Delegate layout change + R2R version bump; could invalidate R2R images but unlikely to affect this micro benchmark's hot path
    • 36812f06f261 - JIT R2R direct-call marking; not related to GetType
    • 3d40d73dd958 - JIT CORINFO_HELP_BOX recognition; unrelated to type reflection
• Verification Status: Not verified — bisection recommended to confirm

Noise Tests

None — the single reported regression is confirmed as a genuine step change.

Open Questions

• Verification Needed: While the attribution confidence is very high (surgical commit match + precise timing), verification via RunWithBuildAtHash comparing the parent commit (0080389) against d04703b would provide definitive confirmation.
• Arm64-specific impact: The commit shows x64 codegen improvements in its PR description. The regression on arm64 suggests the folded code path may have different performance characteristics on Ampere hardware — possibly due to branch prediction, instruction cache effects, or the null-check code shape on arm64.

Recommended Actions

1. Verify regression: Run bisection or targeted comparison with RunWithBuildAtHash on commits 00803896e74e and d04703b52beb to confirm the exact culprit commit.
2. Investigate arm64 codegen: Review the JIT-generated arm64 assembly for TypeReflectionObjectGetType before and after the change to understand why the folded GetType() path is slower on arm64. Collecting hardware counters (branch mispredictions, cache misses) may help diagnose.
3. Engage author: Notify EgorBo about the arm64 regression — the optimization improves x64 codegen but appears to regress arm64 performance for this pattern.

Bisection Results

Test	Status	Culprit Commit	Relevance	Reported Diff (issue)	Bisected Diff (at culprit)	Duration
TypeReflectionObjectGetType	✅ Success	d04703b52beb	✅ RELATED	33.4→44.6 μs (+33%)	33.4→44.6 μs (+33%)	701s

Total bisection time: 701s
Success rate: 1/1 tests

PerfLabTests.LowLevelPerf.TypeReflectionObjectGetType

• Culprit: d04703b52beb
• Commit Message: Don't give up on folding obj.GetType if obj can be null (Don't give up on folding obj.GetType if obj can be null #129371)
• Relevance: RELATED
• Explanation: This commit modifies JIT value numbering logic for obj.GetType() folding in gentree.cpp and valuenum.cpp. The benchmark TypeReflectionObjectGetType directly measures GetType() performance. The change alters how the JIT folds GetType() calls when the object may be null, adding additional null-check exception set handling that plausibly adds overhead to the hot path.

Helix jobs

Job ID	Submitted by bisection	Last status
3dd2214c-f4a9-42fc-ba19-aac8bd602c5d	✅	submitted
2c11553e-4be6-4256-8a81-4147e6adb553	✅	submitted

Per-commit measurements

Commit	Position	Measurements
dabcb41841ff	q1	33.444 μs
07b0630df574	q3	44.584 μs
36812f06f261	index 11	33.444 μs
2198d5d0032b	index 12	33.445 μs
00803896e74e	index 13	33.445 μs
d04703b52beb	index 14	44.579 μs
24097f23dbca	mid	33.446 μs

Bisection details

…[earlier output omitted]

• 00803896e74e (index 13): 33445.46 ns ✓ (baseline)
• d04703b52beb (index 14): 44578.98 ns ✗ (regressed)

The culprit is d04703b52beb11e1385af3f766f605af0949db72. Let me examine it.

● get_single_commit_summary (MCP: PerfTriageMcp) · owner: "dotnet", repo: "runtime", sha: "d04703b5…
└ {"index":null,"sha":"d04703b52beb11e1385af3f766f605af0949db72","abbrevSh...

This commit is directly related to the test. It modifies JIT value numbering for obj.GetType() — which is exactly what the TypeReflectionObjectGetType benchmark exercises. The commit changes how GetType() calls are folded by the JIT, which could affect performance of type reflection operations.

BISECTION RESULT:
- Culprit Commit: d04703b52beb11e1385af3f766f605af0949db72
- Commit Message: Don't give up on folding obj.GetType if obj can be null (#129371)
- Commits Tested: 7
- Confidence: 5
- Commit Relevance: RELATED
- Relevance Explanation: This commit modifies JIT value numbering logic for `obj.GetType()` folding in `gentree.cpp` and `valuenum.cpp`. The benchmark `TypeReflectionObjectGetType` directly measures `GetType()` performance. The change alters how the JIT folds `GetType()` calls when the object may be null, adding additional null-check exception set handling that plausibly adds overhead to the hot path.
- Baseline Value: 33445.46 ns
- Culprit Value: 44578.98 ns
- Summary: Double bisection across 21 commits narrowed the regression to between 00803896e74e and d04703b52beb. The regression (+33.3%) matches the reported delta (+33.4%) and is clearly attributable to JIT changes in GetType() folding.

HELIX JOBS:
- 3dd2214c-f4a9-42fc-ba19-aac8bd602c5d
- 2c11553e-4be6-4256-8a81-4147e6adb553

MEASUREMENTS:
- dabcb41841ff (Q1): 33443.55 ns
- 24097f23dbca (mid): 33446.00 ns
- 07b0630df574 (Q3): 44583.72 ns
- 36812f06f261 (index 11): 33444.32 ns
- 2198d5d0032b (index 12): 33444.88 ns
- 00803896e74e (index 13): 33445.46 ns
- d04703b52beb (index 14): 44578.98 ns

🤖 Proposed Next Actions

Rule: R4_known_regression_new — Known-cause regression — transfer & notify.

Verified regression attributed to commit d04703b (finding 5/5, regression 5/5, bisection RELATED). No prior linked autofile issue found.

#	Action	Status	Details
1	Back-reference cause PR	🕒 Planned	on culprit PR for d04703b52beb
2	Transfer issue	🕒 Planned	→ dotnet/runtime
3	Ping owners	🕒 Planned	no owners resolved
4	Remove label	🕒 Planned	untriaged

🦆 Pre-bisection Re-analysis (advisory)

✅ Agrees with the pre-bisection plan — advisory only, not applied

Rationale: The single candidate has high finding confidence (4/5) and maximum change confidence (5/5) with relevant stack traces and a plausible likely commit, making it a well-justified bisection target. No noisy tests are wasting slots and no actionable findings are being left out.

This critique is advisory in the current configuration and did not change which tests were bisected.

🦆 Re-analysis (advisory)

✅ Agrees with the analysis — advisory only, not applied

Rationale: The bisection converged successfully on d04703b with RELATED relevance and no alignment warning, the per-finding signal is strong (4/5 finding, 5/5 change, noise=False), no bimodal history is flagged, and the overall 5/5 confidences are justified by the bisection confirmation boosting the single finding's 4/5 to the aggregate level.

This critique is advisory in the current configuration and did not change the confidences, culprit, or proposed actions above.

---

Generated by PerfTriageAgent on 2026-06-18 09:01 UTC

[DrewScoggins]

#129371

Related Regression:

• [Perf] Linux/arm64: 1 Regression on 6/16/2026 1:50:56 AM +00:00 perf-autofiling-issues#74732

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.