Closed
Bug 1260475
Opened 8 years ago
Closed 8 years ago
Poor GC throughput due to refresh-triggered slices
Categories
(Core :: JavaScript: GC, defect)
Core
JavaScript: GC
Tracking
()
RESOLVED
FIXED
mozilla48
Tracking | Status | |
---|---|---|
firefox48 | --- | fixed |
People
(Reporter: bugzilla.mozilla.org, Assigned: ehoogeveen)
References
(Depends on 1 open bug)
Details
Attachments
(2 files)
231.59 KB,
image/png
|
Details | |
11.57 KB,
patch
|
terrence
:
review+
|
Details | Diff | Splinter Review |
See attached profiler screenshot. It's spending 28.7% of time in GC slices triggered by the refresh driver and an additional 11.2% in slices triggered by other things. In the past I've turned off project silk vsync settings and that seemed to lessen the impact, but that option has been gone for a while (february?). Anyway, in my case the GC is going to miss the 60fps pause goals anyway, since I've also increased javascript.options.mem.gc_incremental_slice_ms to 40ms, so it would be nice if I could at least improve throughput by turning off refresh-triggered GC slices.
Assignee | ||
Comment 1•8 years ago
|
||
I made a quick patch to add a preference to disable these slice triggers. Could you try the build from this try run that matches your platform (once they're done), and see if it performs any better? https://treeherder.mozilla.org/#/jobs?repo=try&revision=cc88ce7e1de4&selectedJob=18761739 Once the build for a platform is done, the B next to that platform will turn green. If you then click on that B, a panel will pop up, with a link to the build directory next to "Build:" on the lower left. The new preference is called javascript.options.mem.gc_refresh_frame_slices_enabled and can be set to false from about:config. It might need a browser restart to take effect, though I'm not sure.
Assignee | ||
Comment 2•8 years ago
|
||
I won't ask for review on this until we know it helps :)
Assignee: nobody → emanuel.hoogeveen
Status: UNCONFIRMED → NEW
Ever confirmed: true
The GC logs don't show refresh timer slices, so that part works. I can't compare profiler numbers since it can't resolve symbols for this build. But subjectively the browser does seem to be less sluggish.
Assignee | ||
Comment 4•8 years ago
|
||
Comment on attachment 8736014 [details] [diff] [review] Add an option to disable GC slices triggered by painting. Great, I'll ask for review on this then. Terrence, this was pretty straightforward, though it's obviously just a mitigation for a situation that I think is hard to fix in general. I wasn't sure if the preference should be exposed to workers - I don't know if those receive NotifyDidPaint at all. If they do, though, it should work just the same as for the main thread GCRuntime, so I propagated the preference for completeness. This is all off by default, so it shouldn't affect behavior normally.
Attachment #8736014 -
Flags: review?(terrence)
The pref also has a positive impact on startup performance: gc_refresh_frame_slices_enabled = false -> 1m11s gc_refresh_frame_slices_enabled = true -> 1m40s
Comment 6•8 years ago
|
||
Comment on attachment 8736014 [details] [diff] [review] Add an option to disable GC slices triggered by painting. Review of attachment 8736014 [details] [diff] [review]: ----------------------------------------------------------------- It would be nice to have this happen automatically in the case where the refresh driver is overloading us. In the meantime, let's take this.
Attachment #8736014 -
Flags: review?(terrence) → review+
Assignee | ||
Comment 7•8 years ago
|
||
(In reply to Terrence Cole [:terrence] from comment #6) > It would be nice to have this happen automatically in the case where the > refresh driver is overloading us. In the meantime, let's take this. Yeah, in general it would be nice to let the mutator run at least a certain percentage of the time, unless it's allocating so quickly that we're falling behind. But this should provide a nicer middle ground at least.
Keywords: checkin-needed
Assignee | ||
Updated•8 years ago
|
Status: NEW → ASSIGNED
Comment 8•8 years ago
|
||
bugherder landing |
https://hg.mozilla.org/integration/mozilla-inbound/rev/aeb9cc61c8ad
Keywords: checkin-needed
Comment 9•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/aeb9cc61c8ad
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox48:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Assignee | ||
Comment 10•8 years ago
|
||
Looks like this made it today's Nightly :) Automatic updates seem to be disabled at the moment, but you can download the latest from http://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
Reporter | ||
Comment 11•8 years ago
|
||
Works on nightly and improves responsiveness after a restart. Sadly performance - ratio of GC time to application time - still is getting worse with uptime. I'll file a separate bug for that once I have some decent profiler output showing the issue. The problem is getting the corresponding GC logs. Is there a way to print them to a file instead of the browser console?
Assignee | ||
Comment 12•8 years ago
|
||
I believe the output can be redirected by setting the MOZ_GCTIMER environment variable to a filename before opening the browser. See also [1] and [2]. [1] https://developer.mozilla.org/en-US/docs/Mozilla/Performance/GC_and_CC_logs [2] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/GC/Statistics_API
Reporter | ||
Comment 13•8 years ago
|
||
Ok, that variable was crashing the content process for me, but I figured it out, it needs security.sandbox.content.level = 0 to work.
Comment 14•8 years ago
|
||
(In reply to The 8472 from comment #13) > Ok, that variable was crashing the content process for me, but I figured it > out, it needs security.sandbox.content.level = 0 to work. That sounds like a bug in the patch. What is the crash report for the crash that you got?
Flags: needinfo?(bugzilla.mozilla.org)
Reporter | ||
Comment 15•8 years ago
|
||
I meant the MOZ_GCTIMER environment variable, that one crashes the content process. crash report is bp-c5ae5232-1dfd-4b52-bd24-ab6fa2160402
Flags: needinfo?(bugzilla.mozilla.org)
Comment 16•8 years ago
|
||
Thanks, I filed bug 1261850 about that issue.
Reporter | ||
Comment 17•8 years ago
|
||
Filed bug 1262321 about the remaining throughput problems.
You need to log in
before you can comment on or make changes to this bug.
Description
•