-
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
JIT: Libraries PGO assert during find loops #59666
Comments
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsThis is from windows arm64; it may fail on other os/arch combos too.
|
cc @dotnet/jit-contrib |
@AndyAyersMS A side comment: the repro has randomness from (1) JitRandomEdgeCounts, (2) JitRandomGuardedDevirtualization, (3) Tiered compilation, (4) Tiered PGO. Possibly (1) and (2) aren't too random due to a hash-based random number seed? And (4) is not actually random? So the real randomness is from (3)? A question is: can we collect "side data" from the randomness on a win/arm64 run that we can replay using an altjit on win/x64 to reproduce the issue? Presumably, we could do this using the existing record/replay mechanism of SuperPMI today already, if we implemented #41649? Regarding this issue: did it come from the experimental pipeline? |
It's from our regular weekend CI runs: https://dev.azure.com/dnceng/public/_build?definitionId=1002&_a=summary Yes, true randomness here is likely from variability in what gets tiered up, for libraries runs (given high level of concurrency and load) this can fluctuate quite a bit from run to run. And of course changes in libraries code (eg Regex was revised recently to support source generation...) can alter things too. The side data collection would be nice addition -- the idea I had was to always be collecting SPMI data for these runs but (on the fly) toss out the MC's for any method that jits successfully. Not sure how feasible this is. |
Failed again over the weekend: |
Suspect this was fixed by #69878. Haven't seen it happening recently. |
This is from windows arm64; it may fail on other os/arch combos too.
The text was updated successfully, but these errors were encountered: