From the docs, the implementation is optimized to take advantage of there being a small set of monotonically growing threads at work. To this end, it seems e.g. BirthOnThread objects are considered immortal. Pointers to those are stored in PendingTask instances, which live as long as their corresponding tasks.
Consider the case where task T is created on thread A, and posted with a delay to somewhere else. There is now a pointer to the BirthOnThread instance relating to thread A in T, from how I read the (excellent) docs.
I have not reviewed the code in detail, so this may all be hokum.

Looks like there is cleanup of sorts on thread termination. See <https://cs.chromium.org/chromium/src/base/tracked_objects.h?q=first_retired&l=643&dr=CSs>.
However, this has an assumption that retired and newly created unnamed threads are of a kind, and thus reuses ThreadData promiscuously across thread exit/creation.
If the scheduler has multiple different kinds of dynamically sized thread pools, and/or ever retires "named" threads, this won't work right, and will lead to birth/death data bleeding across thread types, which should be confusing.
I'm guessing it'd be fairly easy to fix this by making sure that any ThreadData is only re-used by another thread of the same name and/or kind.

I think this audit should block making the TaskScheduler on by default (and maybe the fix depending on the result of the audit).

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

commit f607a846cc997adf49d621388a3fd3ce9b6956e1
Author: fdoray <fdoray@chromium.org>
Date: Tue Dec 06 21:44:48 2016

Reuse ThreadData instances associated with terminated named threads.

With this CL, whenever a thread is terminated, its ThreadData is added
to a retired list. When a thread which doesn't have a ThreadData yet
needs one, we first check if a ThreadData from the retired list could be
reused. A ThreadData can be reused if it was previously associated with
a thread that had the same name as the current thread, ignoring trailing
digits. If no ThreadData can be reused, a new one is allocated.

This change is important because TaskScheduler tears down its named
threads when they aren't used for a while and recreates them when they
are needed. We don't want this behavior to increase the number of
ThreadData instances in the process indefinitely over time.

BUG= 645196 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

[modify] https://crrev.com/f607a846cc997adf49d621388a3fd3ce9b6956e1/base/tracked_objects.cc
[modify] https://crrev.com/f607a846cc997adf49d621388a3fd3ce9b6956e1/base/tracked_objects.h
[modify] https://crrev.com/f607a846cc997adf49d621388a3fd3ce9b6956e1/base/tracked_objects_unittest.cc
[modify] https://crrev.com/f607a846cc997adf49d621388a3fd3ce9b6956e1/chrome/browser/task_profiler/task_profiler_data_serializer.cc
[modify] https://crrev.com/f607a846cc997adf49d621388a3fd3ce9b6956e1/chrome/browser/task_profiler/task_profiler_data_serializer_unittest.cc
[modify] https://crrev.com/f607a846cc997adf49d621388a3fd3ce9b6956e1/components/metrics/profiler/profiler_metrics_provider.cc
[modify] https://crrev.com/f607a846cc997adf49d621388a3fd3ce9b6956e1/components/metrics/profiler/profiler_metrics_provider_unittest.cc
[modify] https://crrev.com/f607a846cc997adf49d621388a3fd3ce9b6956e1/components/metrics/profiler/tracking_synchronizer_unittest.cc
[modify] https://crrev.com/f607a846cc997adf49d621388a3fd3ce9b6956e1/content/common/child_process_messages.h
[modify] https://crrev.com/f607a846cc997adf49d621388a3fd3ce9b6956e1/tools/metrics/histograms/histograms.xml

Race ( issue 672852 ) fixed. What's left here? Reporting sequence #s on profiler dashboard?

Dynamic threads no longer cause an infinite growth of profiling memory.

Reporting sequence #s on profiler dashboard is a separate issue https://crbug.com/670099