Closed
Bug 410291
Opened 17 years ago
Closed 12 years ago
Windows working set / private bytes regression on 12/29 (suspect bug 399587)
Categories
(Core :: XPConnect, defect, P1)
Tracking
()
RESOLVED
WORKSFORME
mozilla1.9.1
People
(Reporter: sayrer, Assigned: mrbkap)
References
()
Details
(Keywords: memory-footprint, regression)
Visible on the tinderbox talos machines.
Looks like mrbkap is the only one in the checkin window, so assigning to him.
Flags: blocking1.9?
Reporter | ||
Updated•17 years ago
|
OS: Mac OS X → Windows XP
Updated•17 years ago
|
Summary: Windows working set / private bytes regression on 12/20. → Windows working set / private bytes regression on 12/29.
Updated•17 years ago
|
Keywords: footprint,
regression
Updated•17 years ago
|
Version: unspecified → Trunk
Assignee | ||
Comment 1•17 years ago
|
||
huh, I don't see how either of those patches could have increased the working set so much without leaking. I'll look into it as soon as I can.
Comment 2•17 years ago
|
||
We should figure this out one way or the other - +ing
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Comment 3•17 years ago
|
||
I noticed this when looking at the graphs to see what jemalloc had brought us, and was a little shocked to see that we haven't brought it back down.
cc'ing stuart who might have some ideas
Seems to have been caused by mrbkap's checkin of bug 399587, which was then backed out by jruderman, and then checked back in after mrbkap fixed bug 410323. When it went back in, the regression returned. It's been there ever since.
Priority: P2 → P1
Target Milestone: --- → mozilla1.9beta4
Updated•17 years ago
|
Summary: Windows working set / private bytes regression on 12/29. → Windows working set / private bytes regression on 12/29 (suspect bug 399587)
Comment 4•17 years ago
|
||
Oh, nevermind, I should have checked the dependencies, looks like the fix is in bug 410223.
Assignee | ||
Comment 5•17 years ago
|
||
Now that bug 410223 has been checked in, we should keep an eye on these numbers to see if they go back down.
Comment 6•17 years ago
|
||
The regression is still there, on XP talos.
![]() |
||
Updated•17 years ago
|
Assignee: mrbkap → honzab
How bad was the regression here? Bkap is pretty swamped with security fixes so there's a good chance we won't get this fixed for release unless we think this is stop-ship bad. Does anyone remember a percentage?
Comment 8•17 years ago
|
||
Very easy to find:
http://graphs.mozilla.org/#spst=range&spss=1198954495.3714285&spse=1199029859.7485714&spstart=1196881975&spend=1203476358&bpst=Cursor&bpstart=1198954495.3714285&bpend=1199029859.7485714&m1tid=53222&m1bl=0&m1avg=0&m2tid=53258&m2bl=0&m2avg=0&m3tid=53240&m3bl=0&m3avg=0&m4tid=53280&m4bl=0&m4avg=0
Goes from ~69MB to 72MB so definitely noticeable so I wouldn't punt this. Do we have no idea what's going on here?
From Blake:
"I have one idea left on this and am trying to figure out the easiest way to implement it -- after that, I have no clue how or why the original patch could have caused (such a large) private bytes regression."
So I guess lets try that one before pushing the panic button. An alternative strategy would be to try to do it in a dot release, but it's scary to punt something without knowing how risky the fix would be.
Updated•17 years ago
|
Priority: P1 → P2
Target Milestone: mozilla1.9beta4 → mozilla1.9
Updated•17 years ago
|
Flags: tracking1.9+ → blocking1.9+
Updated•17 years ago
|
Assignee: honzab → mrbkap
Reporter | ||
Comment 10•17 years ago
|
||
Line 527 in XPCCrossOriginWrapper looks suspicious.
<a href="http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/XPCCrossOriginWrapper.cpp&rev=&cvsroot=/cvsroot#527">http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/XPCCrossOriginWrapper.cpp&rev=&cvsroot=/cvsroot#527</a>
I noticed that XPCWrappedNativeScope::mWrapperMap is not inspected by the cycle collector.
Comment 11•17 years ago
|
||
(In reply to comment #10)
> Line 527 in XPCCrossOriginWrapper looks suspicious.
>
> <a
> href="http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/XPCCrossOriginWrapper.cpp&rev=&cvsroot=/cvsroot#527">http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/src/XPCCrossOriginWrapper.cpp&rev=&cvsroot=/cvsroot#527</a>
>
> I noticed that XPCWrappedNativeScope::mWrapperMap is not inspected by the cycle
> collector.
>
Easy to remedy?
Sayre, if you have ideas for a patch it'd be great to have to try out. Blake is very short on time these days what with finals and such.
Comment 13•17 years ago
|
||
Not blocking on this bug, but we'd still love a fix...
Flags: wanted1.9.0.x+
Flags: blocking1.9-
Flags: blocking1.9+
Priority: P2 → P1
Comment 14•17 years ago
|
||
(In reply to comment #13)
> Not blocking on this bug, but we'd still love a fix...
>
Er - why?
Comment 15•17 years ago
|
||
Because we have more important bugs to fix. *I* (nor Jonas) wouldn't not hold the release for this. If you disagree, please plus/renom this again.
Comment 16•17 years ago
|
||
renominating for blocking based on comment 10
Someone at least needs to look at this...
Flags: blocking1.9.2?
Flags: blocking1.9.1?
Target Milestone: mozilla1.9 → mozilla1.9.1
Comment 17•17 years ago
|
||
Not blocking the release on this, but it'd be great to know where to go here...
Flags: blocking1.9.1? → blocking1.9.1-
Updated•16 years ago
|
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
Assignee | ||
Comment 18•12 years ago
|
||
This has almost certainly been fixed in the meantime.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•