Closed Bug 1170034 Opened 9 years ago Closed 8 years ago

Regression: GC jank in Firefox 39 not present in 38

Categories

(Core :: JavaScript: GC, defect)

39 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: tyaremco, Unassigned)

References

Details

Attachments

(1 file)

130.67 KB, application/zip
Details
Attached file profile.zip
Perf profile attached.
Component: General → JavaScript: GC
Product: Firefox → Core
It seems to get worse while/after I've been typing in textareas...
http://people.mozilla.org/~bgirard/cleopatra/#report=c9156fa3444f04983fba2dbebed9d2061d626a8a&jankOnly=true
Hmm, the profiles show most of the time being spent in a long tail of unsymbolicated addresses - JIT code perhaps? The last profile (from comment #3) shows a significant chunk of time in the cycle collector. The GC slices look relatively short and well-behaved in all three profiles as far as I can tell (keeping in mind that I'm no expert at reading profiles).

Do you still see the same behavior in Beta, Dev Edition or Nightly? Without a specific test case or symbols in the profile I don't know how actionable this is. 

The look of the profiles reminds me of bug 1154080, which I filed, but that regressed and was fixed while Firefox 40 was the Nightly. Could be a similar problem though - many stubs being generated and then not used. I'll tentatively switch this to the JIT component.
Status: UNCONFIRMED → NEW
Component: JavaScript: GC → JavaScript Engine: JIT
Ever confirmed: true
This is difficult to get down to a proper use-case, but I can say this so far:

There is a large firefox.exe CPU spike (>50%) that is directly responsible for the browser hang. This spike occurs precisely after 40 seconds of idle time.  By idle time, I mean 'not clicking'.  Moving the mouse or scrolling does appear not reset the idle time.

I still am trying to get a use case where I can reproduce the hang consistently, but whenever I _can_ reproduce it, it _always_ occurs at the 40s mark of idle.  In fact, I find that if I click anything before 40s (to cancel the idle time) the CPU spike does not occur.


Regarding which version are effected: when I initially filed the bug, I confirmed it on Firefox 39-41.  I'll try on the latest nightly...
Component: JavaScript Engine: JIT → JavaScript: GC
I see - that does sound like GC then (perhaps the idle triggered compacting GC), and it sounds like the idle detection is broken.
Yep, disabling

> javascript.options.mem.gc_compacting

makes a massive difference!  I can still get the browser to hang briefly at 40s idle under certain circumstances but for my regular browser usage this work-around essentially fixes the problem.
Flags: needinfo?(terrence)
Looks like bug 1130439 then.
Blocks: 1130439
Yes, definitely seems like our idle heuristics for CGC are incorrect. Who should we bug on the gecko side of the fence to help figure out what we actually need to be waiting on here?
Flags: needinfo?(bzbarsky)
I'm not sure offhand.  Maybe smaug or avih knows?
Flags: needinfo?(bzbarsky)
> By idle time, I mean 'not clicking'.  Moving the mouse or scrolling
> does appear not reset the idle time.

How does typing affect this?  Your earlier comment said that typing made it worse.  Do you find that typing also does not reset the idle time?

The idea is that we perform a compacting GC when the user is inactive, but it seems that the way we detect this isn't working properly.
Flags: needinfo?(tyaremco)
I'm not able to reproduce this on Linux.  Moving the mouse, scrolling and typing all correctly reset the inactivity timeout and prevent compacting GC from happening.  I don't have access to a windows box right now to test on unfortunately.
Testing on Windows a virtual machine showed the inactivity timer being reset correctly by moving the mouse and by typing.

Something strange that did happen was that I saw continual user-interaction-active events every couple of seconds while the mouse was over the main window.  I don't know whether that's a bug or related to running it in a virtual machine.
No longer an issue.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(tyaremco)
Resolution: --- → INVALID
Flags: needinfo?(terrence)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: