(Wrong scheduler. Don't know what's the right one).

Sorry, I just verified the size of each Task object. It looks like 30,000 tasks are in the queue. (2.5MB / 80 bytes)

Interesting. Some pages do post tasks faster than they processed and the tasks just pile up.

If we're lucky a significant proportion these tasks might have been cancelled in which case we could consider sweeping them away periodically.  If not we probably need to reach out to facebook and explain the problem.

I think Alex has a patch for this in progress.

Yes I have a patch in the works to periodically sweep canceled delayed tasks.  Some usage patterns for DOM timers can really cause them to pile up (basically repeatedly posting and canceling a setTimeout with a long delay).  Of course if the page is posting tasks father than they can be consumed there's not much we can do about that.

*faster than they can be consumed.

I think it cannot be the case where Facebook is creating tasks at such a rate where it gets accumulated over a day to 30000, when it's idle. It will mean that whole day it has been doing tasks, consuming cpu all day. Also I found that it was using similar memory in another trace I took few hours earlier. 

Attaching stack trace in case it's useful.

Deleted: task_queue_vector.png 126 KB

	task_queue_vector.png 126 KB View Download

Can you take a trace with disabled-by-default-renderer.scheduelr.dbg?  That will let us know if the tasks are cancelled or not.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5

commit fd870526d2ed5a6b3577b46aa9f01532b15bc6d5
Author: alexclarke <alexclarke@chromium.org>
Date: Mon Jan 16 12:47:00 2017

Add an idle task to periodically sweep canceled delayed tasks

It turns out canceled delayed tasks can really pile up for some pages where they
repeatedly post dom timers with long delays and cancel them.

This patch adds an idle task which every 30s sweeps away all canceled delayed tasks.
We also add the concept of PostDelayedIdleTask to do so.

PostDelayedIdleTask posts a task which is eligible to run after the next time an idle
period starts. I.e. this has after wakeup semantics, i.e. unless something else wakes
the CPU up, it won't run.

BUG= 680815 

Review-Url: https://codereview.chromium.org/2637463002
Cr-Commit-Position: refs/heads/master@{#443877}

[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/BUILD.gn
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/base/task_queue_impl.cc
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/base/task_queue_impl.h
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/base/task_queue_manager.cc
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/base/task_queue_manager.h
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/base/task_queue_manager_unittest.cc
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/child/compositor_worker_scheduler.cc
[add] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/child/idle_canceled_delayed_task_sweeper.cc
[add] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/child/idle_canceled_delayed_task_sweeper.h
[add] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/child/idle_canceled_delayed_task_sweeper_unittest.cc
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/child/idle_helper.cc
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/child/idle_helper.h
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/child/idle_helper_unittest.cc
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/child/scheduler_helper.cc
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/child/scheduler_helper.h
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/child/single_thread_idle_task_runner.cc
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/child/worker_scheduler_impl.cc
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/child/worker_scheduler_impl.h
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.h
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/public/platform/scheduler/child/compositor_worker_scheduler.h
[modify] https://crrev.com/fd870526d2ed5a6b3577b46aa9f01532b15bc6d5/third_party/WebKit/public/platform/scheduler/child/single_thread_idle_task_runner.h

Holy cow, we're shipping M56 to stable this week for desktop and next week for Android, there is *no way* we can take a patch of the size of the one in c#9 right now.

How bad is this regression, which is currently marked as a Pri-2?  What platforms does it impact?  If this has really high impact and we can't get a more simplified patch we're going to have to make some really hard decisions by tomorrow morning.

Please see Issue 676082 for the original genesis of this bug. The bottom line is there's a large memory leak somewhere but no one has confirmed the true cause or knows the full scope of affected users.

The memory issues fixed by https://codereview.chromium.org/2637463002 where introduced by the blink scheduler launch well over a year ago.  I don't see why this should block M56.  

Incidentally please don't take that to mean I think memory concerns are trivial.  I sit opposite the memory infra folks and I support what they're doing :)  Just M56 is almost here and I doubt 6 waiting an extra 6 weeks will hurt since it's been broken for ages.

Yeah, I'm going to remove RB-Stable given that.  Can we please get an accurate OS tagging please?  Issue 676082 is Linux, Mac - is that really all that's impacted here?

This no longer appears in my testing. Thanks!