Add New Test to Track Number of Jitted Methods#91235
Add New Test to Track Number of Jitted Methods#91235ivdiazsa merged 24 commits intodotnet:mainfrom ivdiazsa:jitted-parts
Conversation
ghost
assigned
|
Tagging subscribers to this area: @hoyosjs Issue DetailsAddresses issue #88533. This PR adds a new test that monitors the number of jitted methods in a simple console app. The purpose is to catch big methods regressions faster.
|
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@trylek I had problems with my old fork and had to make a new one, hence a new PR. PTAL |
tree after running the tests, and adjusted the pipelines configuration to only run that one.
other jobs. Disabled the runtime pipeline entirely, and only kept the relevant outerloop platforms for my change to save resources.
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Commands, and disabled the dev-innerloop pipeline to further speed up this testing and debugging process.
|
/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). |
logging all the jitted methods into a file.
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Please do make sure to remove all instrumentation from the yml scripts, most notably I don't see why this PR should be changing |
Good catch. Those changes must have filtered at some point during one of the rebases with main. Will remove them. |
|
Sigh... Windows is causing problems again... Investigating those failures now. |
|
|
||
| // For adding any new apps for this test, make sure they return a negative | ||
| // number when failing. | ||
| int appResult = RunHelloWorldApp(appName); |
There was a problem hiding this comment.
The setup with the app running in a separate process made sense when the test used JIT logging to get the method count.
This setup is overkill now that the test just calls GetCompiledMethodCount and checks its value. Would it be better to turn this into an ordinary single process test that just calls GetCompiledMethodCount and checks its value (and skipping the check in specific environments)?
There was a problem hiding this comment.
Actually, this makes a lot of sense. I just tested it on my local machine and I'm getting 4 jitted methods instead of the 1 I used to get with the solo HelloWorld app. Since the number of jitted methods is very similar, does it make sense to you to do it like this instead @trylek?
some small bad merges in the CI files when rebasing.
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Windows is causing problems, yet again...
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
dotnet app to be fully prejitted, and therefore show 0 jitted methods, so added that case to the test.
|
/azp run runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Failures are unrelated. Merging this now |
| { | ||
| FCALL_CONTRACT; | ||
|
|
||
| // WIP-DEBUG-ONLY change: Windows is causing problems in the CI, but can't |
There was a problem hiding this comment.
This WIP code needs to be reverted!
There was a problem hiding this comment.
Oh I forgot! Good catch, Jan. I will submit a PR fixing that right away.
3 participants
Addresses issue #88533. This PR adds a new test that monitors the number of jitted methods in a simple console app. The purpose is to catch big methods regressions faster.