Don't create redundant ThreadData for Worker Threads

base/tracked_objects.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef BASE_TRACKED_OBJECTS_H_
 #define BASE_TRACKED_OBJECTS_H_
 
 #include <stdint.h>
 
 #include <map>
@@ skipping 433 matching lines @@
     PROFILING_ACTIVE,      // Recording profiles.
     STATUS_LAST = PROFILING_ACTIVE
   };
 
   typedef base::hash_map<Location, Births*, Location::Hash> BirthMap;
   typedef std::map<const Births*, DeathData> DeathMap;
 
   // Initialize the current thread context with a new instance of ThreadData.
   // This is used by all threads that have names, and should be explicitly
   // set *before* any births on the threads have taken place.  It is generally
   // only used by the message loop, which has a well defined thread name.

[jar (doing other things), 2016/04/20 04:34:51]

This comment appears to state that this should *only* be called by threads with
real names, and probably was never meant to be called by worker threads
(transient members of a specific prefixed worker pool).  Perhaps the semantics
have changed, and that is why you must now neuter the call when it is
(surprisingly) called for initialization of a worker thread.

Given your change, you should at least change the first line of this comment
from saying:
"Initialize ... with a new instance of ThreadData"

To instead say:

"If "bool_is_worker_thread|, do partial initialization of the thread context
(and wait for just-in-time initialization by a potentially recycled context),
otherwise fully initialize ...with a new instance of ThreadData."

As I'm writing this, I'm starting to see that there probably *should* be
different recycling pools based on different proposed prefix strings.  If you
"mix up" the different recycling pools, then the contexts will grow much larger
than need be (because they will includes posts from all possible pools, rather
than just from their specific group of threads in a named pool).

Can you verify that various uses of worker-threads handle this properly? 

[Zhenyu Shan, 2016/05/04 23:33:03]

Done.

I'm not very sure if I've understood you correctly. Seems this change only
affects worker threads with prefix "WorkerPool" on posix platforms. There are
other worker pool  based on base::SimpleThread, or base::TaskRunner...Which has
nothing to do with base::WorkerThread.
What do you mean by "mix up" exactly?

-  static void InitializeThreadContext(const std::string& suggested_name);
+  static void InitializeThreadContext(const std::string& suggested_name,
+                                      bool is_worker_thread = false);
 
   // Using Thread Local Store, find the current instance for collecting data.
   // If an instance does not exist, construct one (and remember it for use on
   // this thread.
   // This may return NULL if the system is disabled for any reason.
   static ThreadData* Get();
 
   // Fills |process_data_snapshot| with phased snapshots of all profiling
   // phases, including the current one, identified by |current_profiling_phase|.
   // |current_profiling_phase| is necessary because a child process can start
@@ skipping 345 matching lines @@
   ProcessDataSnapshot(const ProcessDataSnapshot& other);
   ~ProcessDataSnapshot();
 
   PhasedProcessDataSnapshotMap phased_snapshots;
   base::ProcessId process_id;
 };
 
 }  // namespace tracked_objects
 
 #endif  // BASE_TRACKED_OBJECTS_H_