-
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 #65675
Enable QJFL and OSR by default for x64 and arm64 #65675
Conversation
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
|
/azp run runtime-coreclr jitstress, runtime-coreclr outerloop |
Azure Pipelines successfully started running 2 pipeline(s). |
One jit stress failure in baseservices/threading/regressions/13662-a. Also saw this test fail in and earlier OSR PR #63642 (comment), so will need to investigate. |
Haven't been able to repro the stress failure. The test
Might be something timing related? |
Ah, issue is that |
/azp run runtime-coreclr jitstress, runtime-coreclr outerloop |
Azure Pipelines successfully started running 2 pipeline(s). |
/azp run Fuzzlyn, Antigen |
Azure Pipelines successfully started running 2 pipeline(s). |
Latest round of jitstress shows quite a few more failures than the original run. |
Fuzzlyn seems to have run cleanly but failed in some post-processing step (Jakob points out Fuzzlyn currently runs with TC disabled, so OSR won't be a factor here). Antigen failures look like they match up pretty well with the failures from the last rolling run (Sunday). |
Yes, I verified that too. Seems I need to add more flags in Antigen to exercise the OSR code paths. |
One issue is more incompatibility with |
/azp run runtime-coreclr jitstress |
Azure Pipelines successfully started running 1 pipeline(s). |
May still be more fixes needed, similar to the above... still looking. |
This also fails with I'll open a side issue and mark this test as incompatible with stress in the meantime. |
Odd build break building the cross-platform DAC
|
I have added support for OSR stress switches in Antigen in kunalspathak/Antigen@e544a76. Triggering another run. /azp run Antigen |
/azp run Antigen |
Azure Pipelines successfully started running 1 pipeline(s). |
|
|
Seems like something is wiping out huge numbers of test runs. Console log has:
I am going to trigger jitstress on main to try and sort out what's broken, but no point doing that until #65798 or similar lands. |
@AndyAyersMS this is a bug in helix. See https://github.com/dotnet/core-eng/issues/15685; a hotfix is being worked on. |
Ok, thanks.... any idea what we should do about the broken builds issue? |
/azp run runtime |
Azure Pipelines successfully started running 1 pipeline(s). |
Merged in stress fixes and enabling promotion. Will start a new round of testing. |
Seeing some AvxVnni HW tests fail with
will retry |
f2c98ca
to
0ca4006
Compare
This is the main PR to enable OSR, currently blocked by: |
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.
0ca4006
to
561b808
Compare
Libraries failure looks like #60962. |
/azp run runtime-coreclr jitstress, runtime-coreclr outerloop |
Azure Pipelines successfully started running 2 pipeline(s). |
The arm64 jitstress failure in |
@dotnet/jit-contrib think this is finally ready. I need to do one last double-check of the perf numbers before merging. |
Jitstress failure is #60152. @dotnet/jit-contrib ping -- somebody needs to approve this. |
Lots of Ubuntu-Arm64 improvements: dotnet/perf-autofiling-issues#4427 |
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.
See OSR Details and Debugging for more on how this might impact everyone's day to day development.