Open Bug 983611 Opened 6 years ago Updated 1 year ago

Add memory reporter for network channels

Categories

(Core :: Networking, defect, P3)

defect

Tracking

()

People

(Reporter: jduell.mcbugs, Unassigned)

References

Details

(Whiteboard: [MemShrink:P3][necko-backlog])

There's no reporter right now for networking channels, which wind up living for a long time sometimes (IIRC the back/forward history cache keeps a lot of them alive for a long time).

We should start keeping a hashtable of open channels and provide a memory reporter for them.

I'm not sure we need to include the transitive report (i.e. include every byte of every thing that a channel can be related to, like HTTP transactions/connection objects, etc).  That will be very transitive and could be hard to get right (thread safety, etc).  Even just counting the memory for the channel itself and its URIs would be a start here.

We'll probably want to count Child channels for the e10s case (Nicolas: we do memory reporting on child processes I assume?)
Nicholas: see end of last comment.  Also feel free to change memshrink priority :)
Flags: needinfo?(n.nethercote)
s/very transitive/very transient/.   Although it would be transitive too :P
Honza--We could report memory for cache entry too if there's an open one?  IIRC we keep cache entry open for a long time for document-level loads.

See if there's anything else that's taking up memory past OnStopRequest--HttpResponseHead looks like it an obvious one.
Assignee: nobody → honzab.moz
(In reply to Jason Duell (:jduell) from comment #3)
> Honza--We could report memory for cache entry too if there's an open one? 

We already do report all entries.

> IIRC we keep cache entry open for a long time for document-level loads.

Yep.

> 
> See if there's anything else that's taking up memory past
> OnStopRequest--HttpResponseHead looks like it an obvious one.

I'd personally impl a full memory reported and see.  Reporting "just something" is always wrong.
Child processes get reported. If you load about:memory, the first big heading will say "Main Process". If there are any other processes (e.g. the thumbnails process on Firefox desktop, or content processes on B2G or e10s) they get their own sections with their own headings.

When it comes to deciding how important this is and exactly which parts to measure, I thoroughly recommend using DMD to profile first. https://wiki.mozilla.org/Performance/MemShrink/DMD has instructions on how to use it.

Finally, I removed the MemShrink priority, because our standard practice is to leave bugs unprioritized until we've had a chance to look at them in a MemShrink meeting. (Though P2 is almost certainly what we'll end up using!)
Flags: needinfo?(n.nethercote)
Whiteboard: [MemShrink:P2] → [MemShrink]
Whiteboard: [MemShrink] → [MemShrink:P3]
FWIW, the zlib buffers in SPDY session objects are showing up in DMD as taking up a significant amount of space; please make sure you report at least those as well.
Depends on: 986082
Jason, do you have any idea for an owner here?  If not, just bounce back to me.
Assignee: honzab.moz → nobody
Flags: needinfo?(jduell.mcbugs)
Jason asked me to take this one.
Assignee: nobody → hurley
Flags: needinfo?(jduell.mcbugs)
Whiteboard: [MemShrink:P3] → [MemShrink:P3][necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Assignee: u408661 → nobody
You need to log in before you can comment on or make changes to this bug.