Closed Bug 1437828 Opened 7 years ago Closed 7 years ago

Switch devtools to async/await from Task.jsm/yield in devtools/server

Categories

(DevTools :: General, enhancement)

enhancement
Not set
normal

Tracking

(firefox60 fixed)

RESOLVED FIXED
Firefox 60
Tracking Status
firefox60 --- fixed

People

(Reporter: ochameau, Assigned: ochameau)

References

(Depends on 1 open bug)

Details

Attachments

(1 file, 8 obsolete files)

(deleted), text/x-review-board-request
jryans
: review+
Details
Bug 1353542 rewrote Task.jsm for the whole browser/ folder. Bug 1365607 intend to do that for the whole devtools/ folder, but I would like to first start with devtools/server/ as this rewrite isn't that easy and would be easier to do independently. The patches are going to be based on top of Promise.jsm removal for devtools/server in bug 1436978
Blocks: 1438121
Assignee: nobody → poirot.alex
New try run after rebase: https://treeherder.mozilla.org/#/jobs?repo=try&revision=960a0fcad499211da542c245dd6b03a2856b6d42 Note that I had to pull out modification made to devtools/server/tests/mochitest/test_memory_allocations_01.html as this particular test starts failure for obscure reasons when refactoring it to async/await. I opened bug 1438121 for its refactoring. Also note that I attached the xpcshell script I used to generate the two first changesets. But I don't intend to land it. I fixed it to make it work with today's m-c (it was throwing) but I haven't made any modification to its logic. This script comes from Florian in bug 1353542. I intend to merge all of these changesets into a single one and strip command details I added in these individual changesets.
Comment on attachment 8950863 [details] Bug 1437828 - Convert Task.jsm to async/await in devtools/server. https://reviewboard.mozilla.org/r/220100/#review226114 Thanks for working on this! I only skimmed it, but it looks reasonable, and I've successfully used a similar script for RDM.
Attachment #8950863 - Flags: review?(jryans) → review+
Comment on attachment 8950864 [details] Bug 1437828 - Convert generators to sync functions in devtools/server/tests https://reviewboard.mozilla.org/r/220102/#review226118 Thanks, looks good! :)
Attachment #8950864 - Flags: review?(jryans) → review+
I have one blocker left: devtools/client/framework/test/browser_browser_toolbox_debugger.js fails with: A promise chain failed to handle a rejection: eventLoop is undefined - stack: enter@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/utils/event-loop.js:118:5 _pushThreadPause@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/thread.js:180:5 At first sight, the test doesn't cleanup itself correctly (do not remove the breakpoint before closing, while the breakpoint is hit during closing)
Two more patches to try to address debugger test failure. The first first isn't directly related but only helps testing the file locally. The second should, ideally, fix the intermittent visible on try. New try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c73dab2a31a80356a7e950aec6fdadb7c6873559
Comment on attachment 8950865 [details] Bug 1437828 - manual fixes. https://reviewboard.mozilla.org/r/220104/#review226138 ::: devtools/server/tests/mochitest/test_memory_gc_01.html:35 (Diff revision 1) > o[Math.random()] = 1; > objects.push(o); > } > objects = null; > > - await { total: beforeGC } = memory.measure(); > + beforeGC = (await memory.measure()).total; Wow, I am really surprised by the original yield version of this...! I wouldn't have expected it work as written... This cleanup makes it more obvious, so good to see!
Attachment #8950865 - Flags: review?(jryans) → review+
Comment on attachment 8950866 [details] Bug 1437828 - Put spaces before parentheses in "async function()" pattern. https://reviewboard.mozilla.org/r/220106/#review226140
Attachment #8950866 - Flags: review?(jryans) → review+
Comment on attachment 8950867 [details] Bug 1437828 - Manual eslint fix. https://reviewboard.mozilla.org/r/220108/#review226144 ::: devtools/server/tests/unit/test_sourcemaps-16.js:25 (Diff revision 1) > }); > do_test_pending(); > } > > -const testSourcemap = async function (threadResponse, tabClient, threadClient, tabResponse) { > +const testSourcemap = async function (threadResponse, tabClient, threadClient, > + tabResponse) { Hmm, do we have a standard for wrapping params that take more than one line? It's a bit strange to see the next line of params take up the same column as the first line of function body, with no separation between them... Rust uses the style: ``` const testSourcemap = async function ( threadResponse, tabClient, threadClient, tabResponse ) { ``` for long parameter lists (example[1]). Maybe it's reasonable for JS as well? [1]: https://searchfox.org/mozilla-central/rev/d03ad8843e3bf2e856126bc53b0475c595e5183b/servo/components/style/style_resolver.rs#182
Attachment #8950867 - Flags: review?(jryans) → review+
Regarding long parameter list, I'm quite sure this is what prettier does.
Comment on attachment 8950868 [details] Bug 1437828 - Get rid of the now useless require("devtools/shared/task"). https://reviewboard.mozilla.org/r/220110/#review226146 ::: devtools/server/tests/mochitest/test_memory_allocations_01.html:19 (Diff revision 1) > <script src="memory-helpers.js" type="application/javascript"></script> > <script> > "use strict"; > > window.onload = function () { > + let { Task } = require("devtools/shared/task"); Why can't this test be converted to async / await? It's not obvious to me on the first read...
Attachment #8950868 - Flags: review?(jryans) → review+
Comment on attachment 8951000 [details] Bug 1437828 - Allows running brower_browser_toolbox_debugger.js more than once. https://reviewboard.mozilla.org/r/220258/#review226168 Is this test issue related to async / await conversion? It seems a bit random to me... Assuming it is related, I'd like to know if `nukeSandbox` helps instead. ::: commit-message-371dc:1 (Diff revision 1) > +Bug 1437828 - Allows running brower_browser_toolbox_debugger.js more than once. r=jryans Nit: brower -> browser ::: devtools/client/framework/test/browser_browser_toolbox_debugger.js:40 (Diff revision 1) > + > + // Use a unique id for the fake script name in order to be able to run > + // this test more than once. That's because the Sandbox is not immediately > + // destroyed and so the debugger would display only one file but not necessarily > + // connected to the latest sandbox. > + let id = new Date().getTime(); Hmm, could we use `Cu.nukeSandbox` at the end of the test instead of this ID?
Attachment #8951000 - Flags: review?(jryans) → review-
Comment on attachment 8951001 [details] Bug 1437828 - Fix race during test shutdown in browser_browser_toolbox_debugger.js. https://reviewboard.mozilla.org/r/220260/#review226178 Well, it seems good overall, but again, I am not sure I follow how this test is directly related to async / await conversion...
Attachment #8951001 - Flags: review?(jryans) → review+
Comment on attachment 8950868 [details] Bug 1437828 - Get rid of the now useless require("devtools/shared/task"). https://reviewboard.mozilla.org/r/220110/#review226146 > Why can't this test be converted to async / await? It's not obvious to me on the first read... Ah, this is the one about stack frames in bug 1438121. Thanks!
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #28) > Comment on attachment 8951000 [details] > Bug 1437828 - Allows running brower_browser_toolbox_debugger.js more than > once. > > https://reviewboard.mozilla.org/r/220258/#review226168 > > Is this test issue related to async / await conversion? The test start failing because of async/await. But this particular modification is unrelated, it just allow running it multiple times with --repeat. That helps reproducing the intermittent failure that try has. > It seems a bit random to me... Assuming it is related, I'd like to know if `nukeSandbox` > helps instead. I tried many things before coming up with the ID. nukeSandbox is enough. I tried "nukeSandbox + nullify + forceGC + forceCC" but it is still rarely fail to clean it up completely. The most effective of all this was nullify + forceGC, I wasn't sure about utility of others. I could move that particular changeset in another bug as it isn't necessary to land the task refactoring. (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #29) > Comment on attachment 8951001 [details] > Bug 1437828 - Fix race during test shutdown in > browser_browser_toolbox_debugger.js. > > https://reviewboard.mozilla.org/r/220260/#review226178 > > Well, it seems good overall, but again, I am not sure I follow how this test > is directly related to async / await conversion... The switch to async/await somehow changed the timing of breakpoint hit codepath -or- debugger/toolbox closing codepath. I haven't tried to narrow down to what particular Task.jsm removal led to this test failure. But I just found a recent intermittent with the same stack, bug 1438174. This patch should fix it. It may be Promise.jsm and Task.jsm slightly changing the timings altogether. Do you think I should investigate that more before landing?
(In reply to Alexandre Poirot [:ochameau] from comment #31) > (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #28) > > Comment on attachment 8951000 [details] > > Bug 1437828 - Allows running brower_browser_toolbox_debugger.js more than > > once. > > > > https://reviewboard.mozilla.org/r/220258/#review226168 > > > > Is this test issue related to async / await conversion? > > The test start failing because of async/await. > But this particular modification is unrelated, it just allow running it > multiple times with --repeat. > That helps reproducing the intermittent failure that try has. Okay, I agree in general it's good to support that workflow! > > It seems a bit random to me... Assuming it is related, I'd like to know if `nukeSandbox` > > helps instead. > > I tried many things before coming up with the ID. > nukeSandbox is enough. > I tried "nukeSandbox + nullify + forceGC + forceCC" but it is still rarely > fail to clean it up completely. > The most effective of all this was nullify + forceGC, I wasn't sure about > utility of others. > > I could move that particular changeset in another bug as it isn't necessary > to land the task refactoring. Hmm, interesting... Good to see you're trying all the tricks. :) I guess the ID approach is okay then, since that's probably more obvious to readers than various nuking and GC commands. Yes, let's move it to a separate bug assuming it's not need to land task like you said, since this work is already quite large on its own. > (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #29) > > Comment on attachment 8951001 [details] > > Bug 1437828 - Fix race during test shutdown in > > browser_browser_toolbox_debugger.js. > > > > https://reviewboard.mozilla.org/r/220260/#review226178 > > > > Well, it seems good overall, but again, I am not sure I follow how this test > > is directly related to async / await conversion... > > The switch to async/await somehow changed the timing of breakpoint hit > codepath -or- debugger/toolbox closing codepath. > I haven't tried to narrow down to what particular Task.jsm removal led to > this test failure. > But I just found a recent intermittent with the same stack, bug 1438174. > This patch should fix it. > It may be Promise.jsm and Task.jsm slightly changing the timings altogether. > Do you think I should investigate that more before landing? Okay, well, it seems like a reasonable change to the test. I am okay with it given this explanation. Perhaps add some of this to the commit message? I leave it to you to decide if more investigation seems needed. :)
Depends on: 1438508
Depends on: 1438174
Attachment #8950864 - Attachment is obsolete: true
Attachment #8950865 - Attachment is obsolete: true
Attachment #8950866 - Attachment is obsolete: true
Attachment #8950867 - Attachment is obsolete: true
Attachment #8950868 - Attachment is obsolete: true
Attachment #8951000 - Attachment is obsolete: true
Attachment #8951001 - Attachment is obsolete: true
Attachment #8950869 - Attachment is obsolete: true
One last try, with all the changeset squashed into just one: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3cacd69d59af70219ef089e54c77be3bc65b0dd3 This bug now depends on bug 1438508 which depends on bug 1438174.
Pushed by apoirot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3b06c176e18d Convert Task.jsm to async/await in devtools/server. r=jryans
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 60
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: