Reduce the content process leak threshold to something sensible

RESOLVED FIXED in mozilla38

Status

()

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: mccr8, Assigned: mccr8)

Tracking

Trunk
mozilla38
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
I had to bump it up to 2MB because we were hitting an intermittent leak.  It needs to be reduced to something more sensible like 20KB.  This can't really be done until bug 1051230 is fixed so we actually get leak logs most of the time, or it won't be possible to easily tell when regressions are introduced.  I looked at a dozen or so logs recently and didn't see any big leaks, but some TBPL runs with a low threshold and a lot of retriggers is needed before landing.
(Assignee)

Comment 1

4 years ago
20kb seems reasonable with bug 1083897 in place.

With bug 1065117 fixed, it could be further reduced to 5000 bytes.

With bug 1065536 fixed, it could be reduced to 0 bytes.
(Assignee)

Comment 2

4 years ago
Bug 1080096 is an intermittent huge leak, so we should probably fix that before this.
Depends on: 1080096
(Assignee)

Comment 3

4 years ago
Created attachment 8514568 [details] [diff] [review]
Reduce content process leak threshold to 20KB.

I put some notes in the bugs in comment 1 about how the threshold could be further reduced once they are fixed.
Attachment #8514568 - Flags: review?(erahm)
(Assignee)

Updated

4 years ago
Whiteboard: [MemShrink]

Comment 4

4 years ago
Comment on attachment 8514568 [details] [diff] [review]
Reduce content process leak threshold to 20KB.

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

r=me assuming a happy try run w/ the dependencies resolved.
Attachment #8514568 - Flags: review?(erahm) → review+
(Assignee)

Comment 5

4 years ago
here's a try run with a bunch of retriggers, with the full stack of stuff, minus the UDP fix:
  https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=c123693cd56a
There are some leaks in M3, but those all look like the UDP leak, which I have fixed.

Here's a push with the UDP fix:
  https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=4836d88b6fb5

I still need to do a full try run.
Whiteboard: [MemShrink] → [MemShrink:P2]
(Assignee)

Comment 6

4 years ago
It looks like for most tests the leak is down to 1684 bytes, mostly due to ImageBridge (bug 1117203) and a little bit of StoreRef (bug 1116261).  In e10s M1, the leak is 6532 bytes due to GMP.  In e10s M3, it is 8360 bytes, also due to GMP.  The leak is about 2316 bytes in E10s M4 for some reason, maybe due to many StoreRef being leaked (bug 1116261).  1124 bytes leaked in E10s M5.  Anyways, I'm going to leave it at 20kb for now, to let things settle out a bit.  Hopefully I'll be able to land this all today.
(Assignee)

Comment 7

4 years ago
This depends on bug 1083897, because having a low leak threshold is not workable if you are only occasionally getting leak logs, because it will be very hard to figure out when a regression landed.
https://hg.mozilla.org/mozilla-central/rev/e7da7bc52c94
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in before you can comment on or make changes to this bug.