Adjust Blink GC policy for worker threads with few idle periods
Reported by
sigbjo...@opera.com,
Mar 23 2017
|
||||
Issue descriptionIssue 702902 has an example of an (artificial) workload where a worker is kept consistently busy, leaving it without enough of a pause for an idle Blink GC to go ahead. The result being that we have to wait for allocations to ramp up enough for either a conservative GC or a precise GC to be forced. The outcome being a bigger memory footprint until that happens, and possibly a longer pause time when that GC does go ahead. It is worth considering ways to improve on this - a lower time-bound on idle periods for worker threads, force a precise GC sooner if scheduled idle GCs do not go ahead, ...
,
Mar 27 2017
(bug triaging rotation) I'm not sure who is the best owner for this issue for now. (I guess it's someone in TOK arch team?) Could you triage and pass this issue to more appropriate person?
,
Mar 27 2017
keishi@, can you triage this? Is there anything that we, blink-worker team, can help?
,
Mar 27 2017
I'll assign this to myself. I'd like to investigate GC triggering thresholds and marking time on Worker threads. |
||||
►
Sign in to add a comment |
||||
Comment 1 by nhiroki@chromium.org
, Mar 23 2017