Open Bug 981514 (async-stacks) Opened 6 years ago Updated 1 month ago
[meta] Asynchronous call stacks
Chrome 33 added support for linking the call stack of something async back up to the original call site that scheduled the async behavior (setTimeout, etc.). Seems like a neat idea for us to consider too. A little more info is available on their post. : http://www.html5rocks.com/en/tutorials/developertools/chrome-33/#toc-asynchronouscallstacks
Our plan was to add a new console.tagStack() method for the user to opt in to the additional data collection, but it's interesting that they do this automatically. Perhaps the CPU and memory cost isn't that bad after all.
It's not super obvious from Chrome's screenshot, but the "Async" checkbox that appears next to the "Call Stack" panel actually has to be enabled before your code runs. If you hit a breakpoint and then enable "Async" after the fact, no extra information appears (which is slightly confusing UX). I have no idea if this was done for performance reasons, or simply because they can't gather new information once you hit a breakpoint. It does not appear to degrade performance noticeably, but I also haven't tested very much.
Was talking to Erik Bryn (the Ember dude) about this at DHTMLConf. We should totally do this automatically for users (what Chrome is doing now; this bug) but also expose the console.tagStack() method (bug 882825) for user land tagging. Ember manages its own event loop of sorts and they'd love to be able to link where something came from originally instead of only showing a ton of Ember-internal frames.
This is quite awesome! Also just a note: user-land micro-task queues are quite common, in addition to embers run-loop, literally every promise implementation does this as well.
Duplicate of this bug: 1078185
Duplicate of this bug: 1142571
Depends on: 1083359
Summary: Asynchronous call stacks → [meta] Asynchronous call stacks
Component: Developer Tools: Debugger → Developer Tools
Depends on: 1151413
Depends on: 1151414
Paolo, I'm not sure we should enable async stacks by default on 39 for Beta, given that there is still work in progress on bug 1142577 and issues mentioned in bug 1152893. Which other bugs should block enabling this on Beta? Is this ready to ride the trains? We may need to make sure it gets turned off for Desktop as well as mobile?
Please see also bug 981514. It aims for probably the same goal and my experimental work I currently have already gives full walk back (and more.) I'll blog about it soon.
(In reply to Honza Bambas (:mayhemer) from comment #9) > Please see also bug 981514. It aims for probably the same goal and my > experimental work I currently have already gives full walk back (and more.) > I'll blog about it soon. You linked to this bug :P
Interesting mistake :) The bug I mean is bug 1148204.
(In reply to Liz Henry (:lizzard) from comment #8) > Paolo, I'm not sure we should enable async stacks by default on 39 for Beta, > given that there is still work in progress on bug 1142577 and issues > mentioned in bug 1152893. Hi, sorry for the delayed reply. I agree that the before the Async Stacks feature merges to Beta 39 we have to get to a state of consistency as discussed in bug 1152893. The way backwards (and the most likely one for this cycle) would be to back out bug 1140472 (Set an async stack when invoking promise handlers) from late Aurora 39. There might still be other tests written or modified after that bug landed, that depend on it - Nick or Boris will probably be able to help if needed. > Which other bugs should block enabling this on Beta? The way forward is to implement bug 1142577 (Use JS::AutoSetAsyncStackForNewCalls for setTimeout and setInterval) and bug 1158133 (Add a way to disable async stacks, and disable by default on mobile platforms). > Is this ready to ride the trains? We may need to make sure it gets > turned off for Desktop as well as mobile? In fact we may also get bug 1158133 done on its own and turn off the feature on both Desktop and mobile for the 39 cycle. It's unlikely that I'll have time to work on it however, and I'm not familiar with the steps required in the JS engine.
Thanks for the detailed answer! Looks like Nick is out until May 17, Boris is usually quite busy, so can you follow up with this so we can make a decision one way or the other on this and straighten it out by Friday May 8. It sounds like what we need to do is back this out for 39. I would like that to happen before 39 goes to beta, not after.
I'm testing a backout of bug 1140472 on mozilla-central, let's see how it goes. https://treeherder.mozilla.org/#/jobs?repo=try&revision=9fa1cf7d9b5e
Looks like there are a few tests to adjust, but should be quite easy. Filed bug 1163139 which will likely see a patch tomorrow.
5 years ago
You need to log in before you can comment on or make changes to this bug.