1701936 - Annotate GCs with URL

Status: NEW

(Core :: JavaScript: GC, enhancement, P2)

Description

[Jeff Muizelaar [:jrmuizel]]

Here's an example profile where we're spending a bunch of time in GC but there's no way to actually find out what site is causing the problem: https://share.firefox.dev/3wfaQGW

Comment 1

[Andrew McCreight [:mccr8]]

GC time is generally proportional to heap size, so an about:memory report might give you a clue as to what site is the issue.

Comment 2

[Steve Fink [:sfink] [:s:]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #0)

Here's an example profile where we're spending a bunch of time in GC but there's no way to actually find out what site is causing the problem: https://share.firefox.dev/3wfaQGW

A GC can be for any subset of zones, so in the general case we'd need to annotate with a whole list of URLs. With Fission, that's a lot less important, since the GC will only be for one process and that already seems to be annotated (Thread: Isolated Web Content (79/79) in that example profile) and you'll already be looking within one process already by the time you get to a GC marker.

Also, that profile doesn't say to me that GC is necessarily a problem. It's spending a ton of time in GC (564ms and 521ms for the two GCs), but it doesn't appear to be exceeding the budget for any of its slices. Most of the time is spent in marking. So it looks like the site is using a ton of memory, and doing a good job of incrementalizing the GC and only running in idle time. (That's a bit of a guess, so I just filed bug 1701951 for recording this in the profile.)

Perhaps there could be a better way to list out the URLs for a Fission process. At a quick glance, it looks like that profile is for gmail, along with an extension "Tinker Tester Developer Spy". If I were diving into this profile, I'd mostly want an about:memory snapshot or a profile with the (heavyweight) allocation tracking enabled.

That's my take, but I might not be understanding your needs clearly.

Comment 3

[Steve Fink [:sfink] [:s:]]

I'll note that if there is a problem in that profile, then the 154ms and 72.4ms hangs in IdleForgetSkippable would be a good place to start looking. If they're really trying to run in idle time, then why are they going for so long? (Note that the CC would likely be harder to map to URLs.)