-
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
Convert tests under GC subtree to the merged test model #92543
Conversation
Tagging subscribers to this area: @dotnet/area-system-reflection-metadata Issue Detailsnull
|
/azp run runtime-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
When you're ready, you'll probably want to run gcstress because these are the kinds of tests that seem to get worse in that mode. (However, many are GCStressIncompatible and/or RequiresProcessIsolation, so there is less impact that there would be otherwise.) |
GC\Stress\Framework loads the tests from GC\Stress\Tests in ways that I don't fully understand yet, but I suspect there may be some dependencies on the shapes of those tests. |
[This is probably beyond the scope of this PR, but if you have problems in this area, perhaps it is relevant.] The projects in GC\Scenarios\GCSimulator seem strange to me. I think all of them except for the main GCSimulator.csproj could be RunOnly and then maybe not need ReqProcIso, RefXUintWrapGen, AllowUnsafeBlocks, and ItemGroup Compile. Removing over 400 tests from the build seems like it would be noticeable time win too. (Also a Directory.Build.props would simplify this a lot too.) I can contribute to this too - just let me know how you'd like to coordinate with this PR. |
Thanks Mark for your valuable pointers and insights, running GC stress tests is certainly a good idea. For additional cleanups, I agree that the GCSimulator tests are basically 400 calls to the same test with different command-line arguments, my only thinking is that I'd love to first focus on removing all the legacy tests as that will let us get rid of the old variants in the scripts. There are tons of things we can clean up in the tests, in this PR I did some tiny formatting cleanups like converting tabs to spaces and fixing broken alignment here and there but naturally I didn't want to combine this already big change with non-trivial test refactoring. Once the final conversion PRs have been merged in, all subsequent cleanups are up for grabs. |
/azp run runtime-coreclr gcstress0x3-gcstress0xc |
/cc @dotnet/gc |
Azure Pipelines successfully started running 1 pipeline(s). |
Tagging subscribers to this area: @dotnet/gc Issue Detailsnull
|
# Conflicts: # src/tests/JIT/opt/Loops/TripCountOverflow.csproj
/azp run runtime-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
Mark the GC simulator merged runner as a GC-simulator test to avoid launching it just for it to skip every OOP test it executes.
/azp run runtime-coreclr gc-simulator |
No pipelines are associated with this pull request. |
pasting test link here - https://dev.azure.com/dnceng-public/public/_build/results?buildId=789129&view=results |
New GC-simulator build link: https://dev.azure.com/dnceng-public/public/_build/results?buildId=789161&view=results |
Thank you very much @trylek @jkoritzinsky for your work and answering all of my questions about this! From those discussions:
|
@markples it looks like GCSimulator is working now. Also, it's surfacing failures a little more cleanly (explicit scenario failures are actually propagating back from Helix to AzDO and GitHub, which is nice). |
That is great; thanks! |
/ba-g nativeaot timeouts due to helix queue backup |
I've validated that the nativeaot timeouts aren't related. Lets merge this in and get one step closer to removing the legacy test system! |
Co-authored-by: Jeremy Koritzinsky <[email protected]>
No description provided.