Expand CreateSpan in T0

[MichalPetryka]

I've noticed my app allocate 100MB of RuntimeFieldInfoStub instances in the VM implementation while running the T0 code in my app, expanding in T0 should avoid such allocations.

[ghost]

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

Issue Details

---

I've noticed my app allocate 100GB of RuntimeFieldInfoStub instances in the VM implementation while running the T0 code in my app, expanding in T0 should avoid such allocations.

Author:	MichalPetryka
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[MichalPetryka]

@jkotas Could this get a backport to 8.0?

[jkotas]

It is up to the JIT team to make the call on a backport and bring it through the servicing process.

I do not think that this meets the bar for backport to .NET 8. It is by design that T0 compilation consumes extra memory, including extra GC allocations that would be eliminated by full JIT optimizations.

I've noticed my app allocate 100GB of RuntimeFieldInfoStub instances in the VM implementation

Why is not T1 compilation kicking fast enough for your app? It takes a while to allocate 100GB of RuntimeFieldInfoStub, I would expect T1 compilation to kick in a long before this much of RuntimeFieldInfoStub instances get allocated.

[MichalPetryka]

It is by design that T0 compilation consumes extra memory, including extra GC allocations that would be eliminated by full JIT optimizations.

I understand that but with this optimalization pessimizing T0 code so much using it without AggressiveOptimization turns out to be a bad idea, making it effectively useless and a serious performance issue.

It takes a while to allocate 100GB of RuntimeFieldInfoStub

I've actually misread the data, it's able to allocate 100MB, not 100GB. The code in question consists of many hot loops which probably take a lot of time to OSR.

[EgorBo]

I agree with Jan that we already have tons of similar cases in tier0, e.g. Enum.HasFlag (already fixed), also everything related to devirtualizations of interfaces calls on structs when jit can see the exact type (see #90965) and other patterns where only optimized code can get rid of allocations.

We also know that sometimes a method may stay in Tier0 for too long because of the "promotion queue" problem (We had an idea to make it priority-based and e.g. all methods with allocators inside could get a higher priority).

[JulieLeeMSFT]

@MichalPetryka, there are build errors. Please resolve it before merging.

[MichalPetryka]

@MihuBot -tier0

[EgorBo]

@MichalPetryka @MihaZupan is MihuBot failing because of this PR or it's a general issue? Does it fail on other changes?

[MihaZupan]

It's failing somewhere in jit-diff. I'll try it on different PRs now.

[MihaZupan]

Seems like the issue is specifically with this PR and tier 0.
It's working fine on other PRs, or on this PR without the --tier0 flag.

[EgorBo]

/azp list

[EgorBo]

/azp run runtime-coreclr pgo, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

Let's run some pipelines which don't disable TieredCompilation because green inner-loop CI likely means it was never executed in Tier0.

[EgorBo]

/azp run runtime-coreclr outerloop, runtime-coreclr gcstress0x3-gcstress0xc

[EgorBo]

/azp run runtime-coreclr outerloop, runtime-coreclr gcstress0x3-gcstress0xc

Oops, wrong PR 😄

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[EgorBo]

@MihuBot -tier0

[EgorBo]

I've ran jitdiff locally with --tier0 and this PR didn't seem to cause any issues for me so I am going to merge it.

Thanks, @MichalPetryka!