Open
Bug 1380675
Opened 8 years ago
Updated 1 year ago
Consider to not run GC when InvokeInterruptCallback is called
Categories
(Core :: JavaScript: GC, defect, P5)
Core
JavaScript: GC
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox57 | --- | affected |
People
(Reporter: smaug, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
805 bytes,
patch
|
Details | Diff | Splinter Review |
When running some benchmarks, like Speedometer, InvokeInterruptCallback gets called and occasionally that triggers a GC slice. That is pretty much the worst time to run GC slice in such cases.
Could we do something better?
However, Jonco says that running GC there helps with Octane Splay.
Pushed a patch to try to get Windows builds for my testing on QF laptop.
remote: Follow the progress of your build on Treeherder:
remote: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e3cfe0752b48b6a1fb11a8acbedaee3dc20cdae7
remote:
remote: It looks like this try push has talos jobs. Compare performance against a baseline revision:
remote: https://treeherder.mozilla.org/perf.html#/comparechooser?newProject=try&newRevision=e3cfe0752b48b6a1fb11a8acbedaee3dc20cdae7
Reporter | ||
Comment 1•8 years ago
|
||
Locally I get better numbers in Splay but worse in Splay latency
W/O
run1
Splay 12859
SplayLatency 8398
run2
Splay 10742
SplayLatency 7722
With
run1
Splay 14106
SplayLatency 5855
run2
Splay 13764
SplayLatency 5958
Overall score doesn't seem to change much.
Updated•8 years ago
|
status-firefox57:
--- → affected
Priority: -- → P5
Updated•3 years ago
|
Severity: normal → S3
Updated•1 year ago
|
Blocks: GC.performance
You need to log in
before you can comment on or make changes to this bug.
Description
•