-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable QJFL and OSR by default for x64 and arm64 #63642
Conversation
Change these default values when the jit targets x64 or arm64: * COMPlus_TC_QuickJitForLoops=1 * COMPlus_TC_OnStackReplacement=1 The upshot is that on x64/arm64 more methods will be jitted at Tier0, and we will rely on OSR to get out of long-running Tier0 methods. Other architectures continue to use the old behavior for now, as OSR is not yet supported for x86 or arm.
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsChange these default values when the jit targets x64 or arm64:
The upshot is that on x64/arm64 more methods will be jitted at Tier0, Other architectures continue to use the old behavior for now, as
|
@dotnet/jit-contrib FYI -- not yet ready to merge this, but need a PR to kick off a private perf run. |
Merged to pick up stress fixes from #62980 and hopefully better CI health. |
/azp run runtime-coreclr pgo |
/azp run runtime-coreclr libraries-pgo |
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-coreclr jitstress |
Azure Pipelines successfully started running 1 pipeline(s). |
Looks like the various extra test legs are not running cleanly, so expect some failures there. |
Lots of arm64 failures, but suspect it's a bad machine (DDARM64-131) baseservices/threading/regressions/13662 may be a real jitstress failure (w/osr...)
System.Text.Json.Serialization.Tests.StreamTests_Sync.HandleCollectionsAsync may be a real failure in libraries PGO
|
I can repro the On my RPI4, I can repro this about 10% of the time; each run takes ~400s currently, so no insights yet. There is a second failure symptom that crops up too:
Via DumpJittedMethods there are maybe 100 OSR instances created, so it could very well be OSR related. Various attempts at getting this to repro faster and more consistently haven't panned out yet:
Will see if enabling OSR stress gets us anywhere. |
From comparing methods jitted in the passing and the failing runs, if it is OSR, it is likely one of these 4 methods:
|
Via OSR stress, this method seems to cause problems:
|
Think I may have spotted one issue. If the OSR method needs to report generic context, it can sometimes use the context reported by the Tier0 frame, but if that frame didn't report the context, the OSR method needs to report it on the OSR frame. But in On x64 perhaps we get lucky, and that slot tends to be zeroed which is why we didn't see failures? At any rate these two bits of logic need to agree. Testing a fix now. |
Still a bit more work to do on OSR to fix x64 epilog unwind, so am going to close this. |
Change these default values when the jit targets x64 or arm64:
The upshot is that on x64/arm64 more methods will be jitted at Tier0,
and we will rely on OSR to get out of long-running Tier0 methods.
Other architectures continue to use the old behavior for now, as
OSR is not yet supported for x86 or arm.