-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Fixes for partial compilation of methods #80635
Fixes for partial compilation of methods #80635
Conversation
Enable partial compilation of Tier0 methods, using the simple strategy that any stack-empty non-entry non-handler rarely run block is worth deferring. Since Tier0 curently does not access static profile data, this means we mainly defer compilation of blocks with explicit throws. This leverages patchpoints to trigger compilation of the missing parts of methods in a manner similar to OSR. It is enabled for x64 and arm64.
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak Issue DetailsEnable partial compilation of Tier0 methods, using the simple strategy that any stack-empty non-entry non-handler rarely run block is worth deferring. Since Tier0 curently does not access static profile data, this means we mainly defer compilation of blocks with explicit throws. This leverages patchpoints to trigger compilation of the missing parts of methods in a manner similar to OSR. It is enabled for x64 and arm64.
|
@EgorBo PTAL Possibly should mark this as "draft" as I'm not sure it is worth enabling just yet. At any rate this is a trivial change since the PC mechanism has been in the code (and run in various experimental CI legs) for quite a while now. TP impact (per SPMI) will be both interesting and misleading. We hopefully should see a bit of movement in the ASP.NET startup data. |
@AndyAyersMS perhaps worth running some stress tests? |
Sure. Let's see if it makes it through normal CI first |
Not sure if the failures are related or not -- locally I can't repro. Diffs. TP impact is pretty small per SPMI, will be interesting to see on actual apps. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, this is quite the diffs 🙂
Let's also see if TE benchmarks will be affected, e.g. FullPGO ones where we disable R2R
Still a bit puzzled by the failures. I can't repro them so far locally and can't get anything useful out of the core dumps. |
Looks like all the recent pred list stuff is causing PC to faill -- will work up a fix. Also there is one other failure; can't tell for sure if it is the same issue that I mentioned above since CI has purged the logs, but I think it probably is. |
We may have degenerate flow out of a partial compilation block, so make sure to fully remove the block from all successor pred lists. Fixes issue seen in dotnet#80635.
We may have degenerate flow out of a partial compilation block, so make sure to fully remove the block from all successor pred lists. Fixes issue seen in #80635.
Merged to pick up fix from #81605. |
@jkotas I was seeing sporadic failures in OSX/Linux libraries tests. Debugging locally, I could repro a GC suspension timeout -- and while I didn't catch the PartialCompilation helper on the stack it seems likely that the looping /waiting we were doing in there was the culprit. Can you look over how I modified this helper to enable preemptive GC when you get a chance? |
@@ -5219,15 +5219,11 @@ void JIT_Patchpoint(int* counter, int ilOffset) | |||
// Unlike regular patchpoints, partial compilation patchpoints | |||
// must always transitio. | |||
// | |||
void JIT_PartialCompilationPatchpoint(int ilOffset) | |||
HCIMPL1(VOID, JIT_PartialCompilationPatchpoint, int ilOffset) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does JIT_Patchpoint
need the same treatment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't loop, so (at least so far) I've never seen it cause problems.
If it does end up jitting a method, that thread switches to preemptive, and any other threads that hit the patchpoint don't need to wait, they just keep running the Tier0 code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the HELPER_METHOD_FRAME_BEGIN_0
setup need to be moved in front of EECodeInfo codeInfo(ip);
for the same reason you had to move here?
// (but consider: throw path in method with try/catch, OSR method will contain more than just the throw?) | ||
// | ||
LOG((LF_TIEREDCOMPILATION, LL_INFO10, "Jit_PartialCompilationPatchpoint: patchpoint [%d] (0x%p) TRIGGER\n", ppId, ip)); | ||
PCODE newMethodCode = JitPatchpointWorker(pMD, codeInfo, ilOffset); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to also add STANDARD_VM_CONTRACT;
annotation to JitPatchpointWorker
, and make callers switch to preemptive mode before calling it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added.
Arm failure is perhaps another instance of #82252 (which is closed as fixed). |
With the latest commit, PC may be enabling GC at places we wouldn't have GC'd before, so it could be exposing some latent reporting issue. |
Hmm, seems like more widespread problems with contract violations. |
::SetLastError(dwLastError); | ||
ENDFORBIDGC(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ENDFORBIDGC
may need to be before SetLastError
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks -- will reorder these.
Latest Diffs. SPMI sees about at 1.5% TP improvement for minopts, and (I'm guessing) a similar decrease in code size. |
/azp run runtime-coreclr outerloop, runtime-coreclr jitstress, runtime-coreclr pgo, runtime-coreclr libraries-pgo |
Azure Pipelines successfully started running 4 pipeline(s). |
Basic CI tests are all good; extended tests have some issues:
|
Jitstress issue was random PGO stress putting PC patchpoints in blocks with switches; we weren't using the more careful successor iterator and so were seeing duplicate successors. |
/azp run runtime-coreclr outerloop, runtime-coreclr jitstress, runtime-coreclr pgo, runtime-coreclr libraries-pgo |
Azure Pipelines successfully started running 4 pipeline(s). |
Libraries PGO failure:
Looks like emitter accounting is off -- since this is Tier1 (and not OSR) seems like it is probably an existing issue. Looks like it popped up in runs against main done this weekend. @EgorBo let me know if you're going to track this one with a new test monitor issue. CG2 failure is
I am seeing this same failure in recent outerloop runs on main too. |
Sure, let me see if it pops up in different PRs, but presumably indeed worth filing an issue since it should not be connected with your PR directly |
Is it worthwhile to separately PR/merge the various fixes and the |
Yeah, makes sense. I will hijack this PR to push the fixes. |
[edited: was enable PC by default -- we will pursue that in a subsequent PR]
Fix some issues seen with partial compilation in wider testing: