Open Bug 981514 (async-stacks) Opened 6 years ago Updated 1 month ago

[meta] Asynchronous call stacks

Categories

(DevTools :: General, enhancement)

enhancement
Not set

Tracking

(Not tracked)

People

(Reporter: jryans, Unassigned)

References

(Depends on 11 open bugs, Blocks 3 open bugs)

Details

(Keywords: meta)

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[1].

[1]: 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.
Blocks: tagStack
We will have most of the infrastructure for this completed once bug 961325 lands.
Depends on: 961325
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.
Depends on: dbg-inspect
Blocks: dbg-inspect
No longer depends on: dbg-inspect
Summary: Asynchronous call stacks → [meta] Asynchronous call stacks
Depends on: 906239
Alias: async-stacks
No longer blocks: tagStack
Depends on: tagStack
Component: Developer Tools: Debugger → Developer Tools
Depends on: 1152893
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?
Flags: needinfo?(paolo.mozmail)
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
Flags: needinfo?(honzab.moz)
Interesting mistake :)

The bug I mean is bug 1148204.
Flags: needinfo?(honzab.moz)
(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.
Flags: needinfo?(paolo.mozmail)
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.
Flags: needinfo?(paolo.mozmail)
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
Flags: needinfo?(paolo.mozmail)
Depends on: 1163139
Looks like there are a few tests to adjust, but should be quite easy. Filed bug 1163139 which will likely see a patch tomorrow.
Depends on: 1165446
Depends on: 1188510
Depends on: 1200832
Depends on: 1225190
No longer blocks: 1199386
Product: Firefox → DevTools
Blocks: dbg-stacks
Depends on: dbg-captured
Duplicate of this bug: 1244339
No longer depends on: 1142571
No longer blocks: 1110276
Depends on: 1601502
Depends on: 1601504
Depends on: 1601506
Depends on: 1601179
You need to log in before you can comment on or make changes to this bug.