') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); Fix GCStress timeouts in JIT/jit64 by markples · Pull Request #85040 · dotnet/runtime · GitHub
Skip to content

Fix GCStress timeouts in JIT/jit64 - #85040

Merged
markples merged 13 commits into
dotnet:mainfrom
markples:jit64_do
May 18, 2023
Merged

Fix GCStress timeouts in JIT/jit64#85040
markples merged 13 commits into
dotnet:mainfrom
markples:jit64_do

Conversation

@markples

@markplesmarkples commented Apr 19, 2023•
edited
Loading

Copy link
Copy Markdown
Contributor

This includes several changes that seem to help with the timeouts. It might be overkill but seems like a good direction as this has been broken for a while.

  • Change the test wrapper logic to only put one test in a TestExecutor so that the callstacks are much simpler.
  • Factor the test wrapper logic into some helpers to simplify the main method. I also tried to make the "Full" and "XHarness" code generation very similar but didn't try to factor/unify them.
  • Mark several tests as RequiresProcessIsolation so that their gcstress is kept separate from the rest of the tests. Disables a large test under gcstress.
  • Add gcstress striping to some merged groups.

Should fix#85590

@ghostghost assigned markplesApr 19, 2023
@ghostghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Apr 19, 2023
@ghost

ghost commented Apr 19, 2023

Copy link
Copy Markdown

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

null

Author:markples
Assignees:markples
Labels:

area-CodeGen-coreclr

Milestone:-

@markples

markples commented Apr 19, 2023

Copy link
Copy Markdown
ContributorAuthor

/azp run runtime-coreclr gcstress0x3-gcstress0xc

@azure-pipelines

azure-pipelinesBot commented Apr 19, 2023

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@markples

markples commented Apr 19, 2023

Copy link
Copy Markdown
ContributorAuthor

PTAL @kunalspathak (and this should help with the weekend gcstress failure)

kunalspathak
kunalspathak previously approved these changes Apr 19, 2023
View reviewed changes
@build-analysisbuild-analysisBot mentioned this pull request Apr 19, 2023
Closed
@markples

markples commented Apr 20, 2023

Copy link
Copy Markdown
ContributorAuthor

/azp run runtime-coreclr gcstress0x3-gcstress0xc

@azure-pipelines

azure-pipelinesBot commented Apr 20, 2023

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@build-analysisbuild-analysisBot mentioned this pull request Apr 20, 2023
Closed
@markples

markples commented Apr 20, 2023

Copy link
Copy Markdown
ContributorAuthor

/azp run runtime-coreclr gcstress0x3-gcstress0xc

@azure-pipelines

azure-pipelinesBot commented Apr 20, 2023

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@markplesmarkples changed the title Add GCStress striping to jit64_doFix GCStress timeouts in JIT/jit64Apr 20, 2023
@build-analysisbuild-analysisBot mentioned this pull request Apr 20, 2023
Closed
@markples

markples commented Apr 21, 2023

Copy link
Copy Markdown
ContributorAuthor

/azp run runtime-coreclr gcstress0x3-gcstress0xc

@azure-pipelines

azure-pipelinesBot commented Apr 21, 2023

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@markples

markples commented Apr 21, 2023

Copy link
Copy Markdown
ContributorAuthor

@trylek@davidwrighton We've been having gcstress timeouts occur every time we add merged test groups. The behavior has indicated some degradation over time within a gcstress process (probably the original motivation for striping). However, we've also seen individual tests take much longer, even when first or early in a merged test group run. My new theory is that the extra stack frames have a prohibitively high cost (and like it's just the test executor methods with the N try/catch blocks).

The current iteration of this PR is (overly) aggressive at simplifying the stack. It also still marks several tests as RequiresProcessIsolation as leftover from my initial experiments. Before I go further, I was hoping to get some feedback on the area. My thought is to just go to one test per TestExecutor (and therefore simplify the logic there), make XHarnessTestRunner match it for consistency, and keep the RPIs in order to get gcstress testing unblocked. They can be removed in the future, though this is low priority since individual tests don't hurt test throughput too much.

@markples

markples commented Apr 21, 2023

Copy link
Copy Markdown
ContributorAuthor

/azp run runtime-coreclr gcstress0x3-gcstress0xc

@azure-pipelines

azure-pipelinesBot commented Apr 21, 2023

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@markples

markples commented Apr 25, 2023

Copy link
Copy Markdown
ContributorAuthor

fyi - I'm now looking at using BuildAsStandalone in gcstress builds to completely avoid merged test groups for now. See #85284 though it will probably take a few rounds for me to get the yaml right.

@trylek

trylek commented May 4, 2023

Copy link
Copy Markdown
Member

@markples - Do you think we might be able to reduce some of these costs by emitting calls to the individual test entrypoints through helper methods so that each such helper method would have just the one try-catch block?

@markples

markples commented May 4, 2023

Copy link
Copy Markdown
ContributorAuthor

@trylek This PR currently does that (it was easy by setting the grouping value to 1). I think that it helped but still hit a problem (though it's been long enough that I don't remember the details), which is why I had shelved this and was trying the BuildAsStandalone thing. However, that has hit an issue that (at least) one of the HardwareIntrinsics projects is big enough to time out (test merging can stripe -within- a project since it is dealing with individual tests).

@markples

markples commented May 5, 2023

Copy link
Copy Markdown
ContributorAuthor

fyi - this is close but I'm waiting for test results

@markplesmarkples mentioned this pull request May 5, 2023
Closed
@markples

markples commented May 11, 2023

Copy link
Copy Markdown
ContributorAuthor

@trylek I propose that we move forward with these fixes for now. They might be overkill, and we might change things again in the future, but this gets jit64 gcstress under control and lets us move forward. A few JIT\Regression legs are still slow but working.

(also resetting @kunalspathak 's review since much has changed since then)

@markples
markples dismissed kunalspathak’s stale reviewMay 11, 2023 23:47

The code has changed a lot

trylek
trylek approved these changes May 12, 2023
View reviewed changes

@trylektrylek left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great to me, thanks Mark!

trylek
trylek approved these changes May 12, 2023
View reviewed changes

@trylektrylek left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great to me, thanks Mark!

@markples

markples commented May 12, 2023

Copy link
Copy Markdown
ContributorAuthor

/azp run runtime-coreclr outerloop

@azure-pipelines

azure-pipelinesBot commented May 12, 2023

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@markples

markples commented May 12, 2023

Copy link
Copy Markdown
ContributorAuthor

MemorySsa is failing elsewhere.

@markples

markples commented May 12, 2023

Copy link
Copy Markdown
ContributorAuthor

running gcstress yet again because my other change restructued the groups

@markples

markples commented May 12, 2023

Copy link
Copy Markdown
ContributorAuthor

/azp run runtime-coreclr gcstress0x3-gcstress0xc

@azure-pipelines

azure-pipelinesBot commented May 12, 2023

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@markples

markples commented May 15, 2023

Copy link
Copy Markdown
ContributorAuthor

/azp run runtime, runtime-coreclr gcstress0x3-gcstress0xc

@azure-pipelines

azure-pipelinesBot commented May 15, 2023

Copy link
Copy Markdown
Azure Pipelines successfully started running 2 pipeline(s).

@markples

markples commented May 16, 2023

Copy link
Copy Markdown
ContributorAuthor

/azp run runtime-coreclr gcstress0x3-gcstress0xc

@azure-pipelines

azure-pipelinesBot commented May 16, 2023

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@markples

markples commented May 17, 2023

Copy link
Copy Markdown
ContributorAuthor

/azp run runtime-coreclr gcstress0x3-gcstress0xc

@azure-pipelines

azure-pipelinesBot commented May 17, 2023

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@markples

markples commented May 18, 2023

Copy link
Copy Markdown
ContributorAuthor

Previous test run might have passed.. but the devops machine flaked out. JIT/jit64 and JIT/opt appear to be ok.

@markples

markples commented May 18, 2023

Copy link
Copy Markdown
ContributorAuthor

/azp run runtime-coreclr gcstress0x3-gcstress0xc

@azure-pipelines

azure-pipelinesBot commented May 18, 2023

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@markples

markples commented May 18, 2023

Copy link
Copy Markdown
ContributorAuthor

Some of the gc stress legs are still quite slow, suggesting more striping would be desirable. Hopefully this current run is sufficient to unblock testing and that striping can be handled separately, but osx arm64 continues to be stubborn with this.

@markples

markples commented May 18, 2023

Copy link
Copy Markdown
ContributorAuthor

Build analysis is showing a failure from a previous run of runtime-coreclr gcstress0x3-gcstress0xc. (perhaps of interest to @JulieLeeMSFT@trylek@ivdiazsa ?)

Failure was in https://dev.azure.com/dnceng-public/public/_build/results?buildId=277134&view=results
Current run is https://dev.azure.com/dnceng-public/public/_build/results?buildId=277895&view=results

@markples
markples merged commit fb0b206 into dotnet:mainMay 18, 2023
@ghostghost locked as resolved and limited conversation to collaborators Jun 17, 2023
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@trylektrylektrylek approved these changes
@kunalspathakkunalspathakAwaiting requested review from kunalspathak

Assignees

@markplesmarkples

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Test Failure - jit64_do.0.1

3 participants

@markples@trylek@kunalspathak