Closed Bug 986082 Opened 6 years ago Closed 6 years ago

add memory reporters for the SPDY zlib buffers

Categories

(Core :: Networking, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla31

People

(Reporter: froydnj, Assigned: froydnj)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

These were taking up enough memory (megabytes for one or two websites) that I decided to split this out into its own bug.
This patch is pretty straightforward: write memory allocation wrappers that
record how much they've allocated, register a new memory reporter, and use the
new wrappers in SpdySession* as appropriate.
Attachment #8394318 - Flags: review?(n.nethercote)
Attachment #8394318 - Flags: review?(mcmanus)
Comment on attachment 8394318 [details] [diff] [review]
add memory reporters for SPDY zlib buffers

Review of attachment 8394318 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm; but I'll pass the review to nick.. as he probably wants to add something similar to the http/2 code. (the http/2 HPACK compression scheme uses considerably less memory though.)
Attachment #8394318 - Flags: review?(mcmanus) → review?(hurley)
Comment on attachment 8394318 [details] [diff] [review]
add memory reporters for SPDY zlib buffers

Review of attachment 8394318 [details] [diff] [review]:
-----------------------------------------------------------------

This is a good start, but it's not ambitious enough. We use zlib in several places, and so this has wider potential use. I can foresee wanting to have multiple ZlibReporters, e.g. we could use one in http://dxr.mozilla.org/mozilla-central/source/js/src/vm/Compression.cpp#14-39.

So to allow that, sAmount can't be static; change it to a normal member. And then move the new files somewhere more generic, probably xpcom/base/. I think that should work.

(This gets me thinking about the other numerous reporters that have |sAmount| in them. Seems like they could be converted to |mAmount| easily enough, and then the |hasRun| check in the constructor wouldn't be needed. I wonder if at some point in the past when reporters were structured differently having |sAmount| made things simpler. Not that it really matters.)

::: netwerk/protocol/http/nsHttpHandler.cpp
@@ +211,5 @@
>  
>      LOG(("Creating nsHttpHandler [this=%p].\n", this));
>  
> +    nsresult rv = RegisterStrongMemoryReporter(new ZlibReporter());
> +    printf("register result: %u\n", uint32_t(rv));

Remove this debugging printf, plz.
Attachment #8394318 - Flags: review?(n.nethercote) → feedback+
Attachment #8394318 - Flags: review?(hurley) → review+
As Patrick said, I'll have to add something similar to the HPACK implementation for HTTP/2 (disabled by default for now, so not a pressing matter). Thanks!
(In reply to Nicholas Nethercote [:njn] from comment #3)
> This is a good start, but it's not ambitious enough. We use zlib in several
> places, and so this has wider potential use. I can foresee wanting to have
> multiple ZlibReporters, e.g. we could use one in
> http://dxr.mozilla.org/mozilla-central/source/js/src/vm/Compression.cpp#14-
> 39.
> 
> So to allow that, sAmount can't be static; change it to a normal member. And
> then move the new files somewhere more generic, probably xpcom/base/. I
> think that should work.

Hm, making it a normal member means that we'd have to have a reference to the memory reporter at the allocation site.  I think it's better to not require that, which will necessitate some trickery.

> (This gets me thinking about the other numerous reporters that have
> |sAmount| in them. Seems like they could be converted to |mAmount| easily
> enough, and then the |hasRun| check in the constructor wouldn't be needed. I
> wonder if at some point in the past when reporters were structured
> differently having |sAmount| made things simpler. Not that it really
> matters.)

Same concern here.
Comment on attachment 8394318 [details] [diff] [review]
add memory reporters for SPDY zlib buffers

Review of attachment 8394318 [details] [diff] [review]:
-----------------------------------------------------------------

Mmm, yes. You're right. In that case, would it make sense to rename it as SpdyZlibReporter?
Attachment #8394318 - Flags: feedback+ → review+
Assignee: nobody → nfroyd
https://hg.mozilla.org/mozilla-central/rev/2de3bb4941ed
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
You need to log in before you can comment on or make changes to this bug.