<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 19, 2020, at 10:24 AM, Geoffrey Garen <<a href="mailto:ggaren@apple.com" class="">ggaren@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 19, 2020, at 8:04 AM, Geoffrey Garen <<a href="mailto:ggaren@apple.com" class="">ggaren@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Can you explain more about what "O3 with no-inlining” is? How does --force-opt=O3 avoid inlining? Would this fully resolve Simon concern about stack traces, or would something still be different about stack traces?</div></div></blockquote>There doesn't exist a way to do this now, but it'd be trivial to add a way. I won't claim it fixes all stack traces differences, but I'd think compiling using<font face="Menlo" class=""> "-fno-inline -fno-optimize-sibling-calls"</font> would get us pretty far in crashing stack traces being similar enough.</div></div></div></blockquote><div class=""><br class=""></div>Sounds good.</div><div class=""><br class=""></div><div class="">I think we should try to refine the proposal along these lines, to minimize the downsides. I won’t speak for Simon, but for me, being able to ensure a clear backtrace from a bot would be a big improvement.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">And again, I think this discussion would get a lot more focused if the change could apply only to JSC code, and not also to WTF code.</div></div></div></blockquote>I believe Mark's proposal, initially, is just to make JSC do this. So I don't see the point of compiling WTF differently. JSC can kick off its own build, and run Debug+O3 tests faster than it can run Debug+O0 tests. Given people working on JSC want this, and people working on JSC defend these tests, and that these test results are more stable (see below), we should make this change for JSC.</div><div class=""><br class=""></div><div class="">I was trying to convince folks defending non-JSC testing, that they too, should want this. I'm not going to pull teeth here. If folks want their tests to take ~10x longer to run, they're entitled to make that tradeoff.<br class=""></div></div></div></blockquote><div class=""><br class=""></div>Got it.</div></div></div></blockquote><div><br class=""></div><div>I'm of the same mind as Saam.  We want this change for the JSC bots, and from the time measurements I’ve collected, we can afford to do a clean build for the JSC Debug test runs using O3, and still come out way ahead.</div><div><br class=""></div><div>As for non-JSC test runs, I have not actually measured what the time savings are.  Given there is resistance to going with O3 there, we don’t have to share the build artifacts for running the tests.  JSC test runs should be able to just build JSC for each O3 Debug JSC test run and it is still a win over the current status quo i.e. test runs never complete.</div><div><br class=""></div><div>Regarding Geoff’s earlier question about whether I know for sure that switching to O3 will fix the current Debug JSC bot failures to run tests, the answer is I’m not certain.  The failure is a timeout due to the master bot not seeing any output from the tester bot for more than 20 minutes.  I’ve not been able to reproduce this yet.  But with a Debug build test run taking 4+ hours, it can only be a progression to switch the Debug JSC test bots to O3.</div><div><br class=""></div><div>Mark</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">And again, on the run more tests front, it would be helpful to know whether this change was enough to get the stress tests running or not.<br class=""></div></div></div></blockquote>My experience running the tests locally supports this fully. I don't get timeouts when running O3+Debug locally. When running Debug+O0 locally, I'd get timeouts all the time, and the total test run would take ~4-8 hours. We can wait for official confirmation from Mark.</div></div></div></blockquote><div class=""><br class=""></div>Alexey, do the JSC stress tests run now on bots? If not, how fast would they need to run in order to be eligible to run on bots?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Geoff</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">- Saam</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Geoff<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jun 18, 2020, at 9:30 PM, Saam Barati <<a href="mailto:sbarati@apple.com" class="">sbarati@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class="">Why are we insisting on doing something on the bots that takes ~10x longer to run than necessary? I’d rather have that time spent running more tests.<div class=""><br class=""></div><div class="">Overall, how we’re doing things now feels like a bad allocation of bot resources. The differences I see between O3 with no-inlining vs O0 is:<div class="">- Some race conditions will behave differently. Race conditions are already non predictable. I don’t think we’re losing anything here.</div><div class="">- O0 vs O3 is a different compiler. We may encounter bugs in O3 we don’t in O0, and vice versa. In general, we probably care more about O3 compiler bugs than O0, since we don’t ship O0, but ship a lot of O3.</div><div class=""><br class=""></div><div class="">(<span style="caret-color: rgb(0, 0, 0);" class="">And if we’re going to insist on “I want it to run what I build at my desk”: I run debug with O3 at my desk, and I can run debug tests in a reasonable amount of time now.)</span></div><div class=""><font class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div class=""><font class=""><span style="caret-color: rgb(0, 0, 0);" class="">In evaluating what’s the better setup, I think it’s helpful to think about this from the other side. Let’s imagine we had Debug+O3 as our current setup. And someone proposed to move it to O0 and make our tests take ~10x longer. I think that’d be a non-starter.<br class=""></span></font><br class=""><div dir="ltr" class="">- Saam</div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On Jun 17, 2020, at 9:48 PM, Simon Fraser <<a href="mailto:simon.fraser@apple.com" class="">simon.fraser@apple.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">I also object to losing good stack traces for crashes on Debug bots.<div class=""><br class=""></div><div class="">Also, I don't think Debug bots should build something different from what I build at my desk.</div><div class=""><br class=""></div><div class="">Simon<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jun 17, 2020, at 1:36 PM, Mark Lam <<a href="mailto:mark.lam@apple.com" class="">mark.lam@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi folks,<br class=""><br class="">We're planning to switch the JSC EWS bot and <a href="http://build.webkit.org/" class="">build.webkit.org</a> Debug build and test bots to building with the following set first:<br class="">./Tools/Scripts/set-webkit-configuration --force-opt=O3<br class=""><br class="">This means the Debug builds will be built with optimization level forced to O3.<br class=""><br class="">Why are we doing this?<br class="">1. So that the JSC EWS will start catching ASSERT failures.<br class="">2. JSC stress test Debug bots have been timing out and not running tests at all.  Hopefully, this change will fix this issue.<br class="">3. Tests will run to completion faster and we’ll catch regressions sooner.<br class=""><br class="">The downside: crash stack traces will be like Release build stack traces.  But I don’t think we should let this deter us.  It’s not like there’s no stack information.  And just as we do with debugging Release build test failures, we can always do a Debug build locally to do our debugging.<br class=""><br class="">We would like to apply this change to all Debug build and test bots, not just the JSC ones.  Does anyone strongly object to this change?<br class=""><br class="">Thanks.<br class=""><br class="">Cheers,<br class="">Mark<div class=""><br class=""></div></div>_______________________________________________<br class="">webkit-dev mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a><br class=""><a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" class="">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br class=""></div></blockquote></div><br class=""></div><span class="">_______________________________________________</span><br class=""><span class="">webkit-dev mailing list</span><br class=""><span class=""><a href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a></span><br class=""><span class=""><a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" class="">https://lists.webkit.org/mailman/listinfo/webkit-dev</a></span><br class=""></div></blockquote></div></div></div>_______________________________________________<br class="">webkit-dev mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a><br class=""><a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" class="">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">webkit-dev mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a><br class="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br class=""></div></blockquote></div><br class=""></body></html>