983611 - Add memory reporter for network channels

Status: NEW

(Core :: Networking, defect, P3)

Description

[Jason Duell]

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?)

Comment 1

[Jason Duell]

Nicholas: see end of last comment.  Also feel free to change memshrink priority :)

Comment 2

[Jason Duell]

s/very transitive/very transient/.   Although it would be transitive too :P

Comment 3

[Jason Duell]

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.

Comment 4

[Honza Bambas (:mayhemer)]

(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.

Comment 5

[Nicholas Nethercote [inactive]]

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!)

Comment 6

[Nathan Froyd [:froydnj]]

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.

Comment 7

[Honza Bambas (:mayhemer)]

Jason, do you have any idea for an owner here?  If not, just bounce back to me.

Comment 8

[u408661]

Jason asked me to take this one.

Comment 9

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 10

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258