Methods JITed during startup

[jkotas]

Repro:

• Build and run Console.WriteLine("Hello world".Replace('e', 'a'));
• Collect list of JITed methods using e.g. perfview

Actual result: String.Replace is JITed in the foreground

Expected result: R2R version of String.Replace is, no JITing of String.Replace observed.

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

Issue Details

---

Repro:

• Build and run Console.WriteLine("Hello world".Replace('e', 'a'));
• Collect list of JITed methods using e.g. perfview

Actual result: String.Replace is JITed in the foreground

Expected result: R2R version of String.Replace is, no JITing of String.Replace observed.

Author:	jkotas
Assignees:	-
Labels:	area-CodeGen-coreclr, untriaged
Milestone:	-

[gfoidl]

Could this be caused by the use of Vector<T> in string.Replace(char, char), and at runtime it's detected that AVX(2) is available, so the method gets JITed?

[danmoseley]

Cc @brianrob

[EgorBo]

crossgen with --singlemethodname Replace --singlemethodtypename System.String --singlemethodindex 3 --verbose:

Info: Method `string.Replace(char,char)` was not compiled because `[S.P.CoreLib]System.Numerics.Vector`1<uint16>` requires runtime JIT

--instruction-set:avx2 fixes it

[jkotas]

Could this be caused by the use of Vector in string.Replace(char, char), and at runtime it's detected that AVX(2) is available, so the method gets JITed?

Yes, it is probably related. However, we should have enough flexibility in crossgen now to make it possible to precompile this successfully (as long as the app is running on current hardware at least).

[EgorBo]

Related: dotnet/designs#173 (and dotnet/core#7131) I assume we're going to default to Avx2 so it kinds of fixes itself

[mangod9]

@trylek @dotnet/crossgen-contrib @richlander . Yeah we have been discussing compiling with avx2 by default.

[richlander]

As @EgorBo raises, it seems like the base question on why the R2R code cannot be used as-is is the basic question. If all non-AVX2 code is thrown out, then that R2R code is useless, right?

Ideally, the following is true:

• All R2R code is used (not just in weird scenarios, but commonly).
• R2R code is optimized for modern hardware.
• R2R code includes high-value (currently) JIT-only optimizations, like guarded de-virtualization, at least for known high-value methods (call-sites or targets).
• The JIT optimizes high-value methods at runtime (tiered comp, dynamic PGO, ...).

As we all know, we are not doing this today. For this conversation, it seems like the first topic is the concern.

[EgorBo]

As @EgorBo raises, it seems like the base question on why the R2R code cannot be used as-is is the basic question. If all non-AVX2 code is thrown out, then that R2R code is useless, right?

Ideally, the following is true:

• All R2R code is used (not just in weird scenarios, but commonly).
• R2R code is optimized for modern hardware.
• R2R code includes high-value (currently) JIT-only optimizations, like guarded de-virtualization, at least for known high-value methods (call-sites or targets).
• The JIT optimizes high-value methods at runtime (tiered comp, dynamic PGO, ...).

As we all know, we are not doing this today. For this conversation, it seems like the first topic is the concern.

From my understanding the main problem that Vector<T> behaves differently in R2R'd code and Tier1 because it's basically of different widths for them, consider the following example:

// This method is Jitted (uses AVX2)
void Method1()
{
    Console.WriteLine(Method2(new Vector<long>(1)));
    // Expected: {2,2,2,2}
    // Actual: {2,2,1,1} or {2,2,0,0} or {2,2,garbage values}
}

// This method is R2R'd with SSE2
Vector<long> Method2(Vector<long> v)
{
    return v * 2;  // {v.long0 * 2, v.long1 * 2 }
}

So we don't allow this to happen and when we see Vector on a non-trimmed path and don't have AVX2 we fallback to JIT.
However it won't happen in e.g.

if (Sse2.IsSupported)
{
}
else if (Vector.IsHardwareAccelerated)
{
 Vector<T>
}

[richlander]

Right. That's my understanding, too. To my mind, our approach doesn't make sense. Why bother R2R-compiling methods that won't be used on most hardware? We should either compile those methods for the most common hardware (not SSE2) or not compile them at all.

non-trimmed path

trimmed? Do you mean tiered?