X64 - Too many methods JITted on startup for blank console application #85791
Comments
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
ghost
added
the
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsUsing this example: namespace HelloWorldStartup
{
internal class Program
{
static void Main(string[] args)
{
}
}
}X64 - With ARM64:
|
TIHan
changed the title
TIHan
added
area-System.Runtime
and removed
area-CodeGen-coreclr
|
Tagging subscribers to this area: @dotnet/area-system-runtime Issue DetailsUsing this example: namespace HelloWorldStartup
{
internal class Program
{
static void Main(string[] args)
{
}
}
}X64 - With ARM64:
|
TIHan
changed the title
|
@MihaZupan can it be caused by SearchValue preinitializations + AVX2? |
|
// cc @stephentoub @tannergooding |
|
Seems like R2R gives up on methods parameterized with static abstract interfaces? Methods like |
|
I'm curious what's triggering these: ? |
Extensive use of reflection in EventSource |
But nothing is registering with EventSource here. Is this all part of manifest generation that happens regardless of whether there are any listeners and that would go away if we finished the source generator? Also, why would those not show up on ARM64... was that also on a different OS and that's impacting what EventSource is doing? |
|
There is always some random ETW session active on my dev machine that turns .NET event tracing on. My guess is that the ARM64 machine that this was measured on was plain vanilla machine without Office, VS, InTune, ... that all tend to create global event tracing sessions in the background. Event tracing is often turned on in the cloud workloads as well. Running with event tracing on may be a lot more common in real world than one would expect. These should go away if we were to build the source generator for EventSource. |
That's concerning, both in terms of startup and in terms of what overheads we might be paying throughout executiion. |
|
Please note that this is an empty app. Add |
Interesting, I see in R2R but no ushort 🤔 |
It's never used with ushort, only byte and char. |
(related issue: #84421) |
🤷 trying to find out who is instanciating that |
|
#85819 removed a couple of methods and now I see 19 for empty app: Found more cases with SVM (crossgen being not able to prejit static virtual methods) cc @trylek |
Do you have System.Console R2R compiled? It only goes up to 30 on my machine and the delta seems to be caused by the bogus SIMD prereqs that should be fixed by #85370 . |
I can confirm 30 methods, but if I do ..\dotnet8p5\dotnet.exe publish -c Release -r win-x64 /p:PublishTrimmed=true /p:PublishReadyToRun=true
$env:DOTNET_JitDisasmSummary=1
bin\Release\net8.0\win-x64\publish\sizedemo.exethen it prints 140. Wonder if that because we re-jit corelib (due to IL trimming) but this time without MIBC (that usually helps crossgen to figure out what's needed to be prejitted aside of default) mibc is not used |
|
Yes, confirmed that MIBC caused that. Ideally, dotnet/sdk should always use our default MIBC for all prejit operations. |
|
I hit the same thing in my Crossgen2 startup perf measurements in the winter. I think we should fix the SDK to pass the MIBC file when |
Did you figure this part out? |
Looks like we have two methods: the latter fails to pick up R2R version, digging further |
|
Ah, SVM again: |
Not following... how does that explain why it compiled a ushort version? |
I assume it's just the way it's displayed in the log (char -> ushort) or maybe R2R is smart enough to share a single version for both char and ushort, but the actual reason we see TryFormatCore in JitDisasmSummary is SVM |
Ok :) |
They will show-up while running a PerfView trace: The second run is when I didn't do a perf-view trace. On my X64 box, even when not running perf-view, the EventSource still gets created, likely from some other program. |
|
For the EventSource ones, anyone know why My and with Many of the extraneous entries have been removed due to improvements in corelib, but corerun is showing all of these dynamicClass entries that dotnet isn't. Is it possible this is a regression? Or is there something different between the hosts that would trigger this? |
What is your exact dotnet version? I have tried this on .NET 8 P7 bits and I do not see this difference. (I see the event source in both cases.) I think it is most likely difference in timing or difference in what kind of event providers get enabled on the machine. The managed providers run asynchronously and the process can be exiting before they get a chance to run in one case, but not in the other case. Also, the Windows monitoring software running in the background can be turning the event providers on - for examble, it can say that |
Using this example:
The CPU I used was an AMD 7950X.
X64 - With
DOTNET_JitDisasmSummary=1it shows this number of methods (this is with R2R):ARM64:
Problems identified:
maxSIMDStructBytesdoesn't reportcompVerifyInstructionSetUnusable#85370)The text was updated successfully, but these errors were encountered: