ServiceWorker: Move worker candidate process knowledge to ServiceWorkerProcessManager.

ServiceWorker: Move worker candidate process knowledge to ServiceWorkerProcessManager.

Before this CL:
Candidate processes info is saved in EmbeddedWorkerInstance, when a new
worker instance is created for a same scope, the info will be absent for
the new worker. E.g., periodic update will spawn a new process every time.

After this CL:
Candidate processes info will be saved in  ServiceWorkerProcessManager
key by registration scope. Then different versions with the same scope could
share this info.

BUG=399982
TEST=content_unittests --gtest_filter=ServiceWorker*

Committed: https://crrev.com/3c4d6ceb7f29eaa4024bfe268e033a2ea296066b
Cr-Commit-Position: refs/heads/master@{#294113}

[xiang, 2014-08-05 06:04:53]

With CL we can avoid spawning unnecessary process for worker for a same scope.
PTAL, thanks!

[falken, 2014-08-05 06:40:19]

+jyasskin

[dominicc (has gone to gerrit), 2014-08-06 06:48:18]

Some comments inline. (Informal review; I am not OWNERs.)

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
File content/browser/service_worker/service_worker_handle_unittest.cc (right):

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
content/browser/service_worker/service_worker_handle_unittest.cc:49: const GURL
scope("http://www.example.com/*");
* has no special meaning in scopes now (scopes are just longest prefix match) so
we should stop writing it.

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
File content/browser/service_worker/service_worker_process_manager_unittest.cc
(right):

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
content/browser/service_worker/service_worker_process_manager_unittest.cc:21:
scope_ = GURL("http://www.example.com/*");
Here too.

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
content/browser/service_worker/service_worker_process_manager_unittest.cc:46: //
Process 3 has the biggest # of references and it should be chosen.
The test would be more discriminative if the output order isn't consecutive by
PID and there's not a 1:1 mapping between PIDs and refs. This will let the test
detect if these were ever mixed up.

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
File content/browser/service_worker/service_worker_version_unittest.cc (right):

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
content/browser/service_worker/service_worker_version_unittest.cc:122: scope_ =
GURL("http://www.example.com/*");
Here too.

[michaeln, 2014-08-08 00:18:39]

jeffrey, can you take a look at this one?

[dominicc (has gone to gerrit), 2014-08-11 01:41:50]

Xiang, can you rebase this patch to HEAD? It looks like some bots couldn't apply
this patch.

[xiang, 2014-08-11 04:50:55]

dominicc@ Thanks for the review!
I have rebased and updated the CL.

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
File content/browser/service_worker/service_worker_handle_unittest.cc (right):

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
content/browser/service_worker/service_worker_handle_unittest.cc:49: const GURL
scope("http://www.example.com/*");
On 2014/08/06 06:48:18, dominicc wrote:
> * has no special meaning in scopes now (scopes are just longest prefix match)
so
> we should stop writing it.

Done.

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
File content/browser/service_worker/service_worker_process_manager_unittest.cc
(right):

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
content/browser/service_worker/service_worker_process_manager_unittest.cc:21:
scope_ = GURL("http://www.example.com/*");
On 2014/08/06 06:48:18, dominicc wrote:
> Here too.

Done.

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
content/browser/service_worker/service_worker_process_manager_unittest.cc:46: //
Process 3 has the biggest # of references and it should be chosen.
On 2014/08/06 06:48:18, dominicc wrote:
> The test would be more discriminative if the output order isn't consecutive by
> PID and there's not a 1:1 mapping between PIDs and refs. This will let the
test
> detect if these were ever mixed up.

Done.

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
File content/browser/service_worker/service_worker_version_unittest.cc (right):

https://codereview.chromium.org/443593002/diff/1/content/browser/service_work...
content/browser/service_worker/service_worker_version_unittest.cc:122: scope_ =
GURL("http://www.example.com/*");
On 2014/08/06 06:48:18, dominicc wrote:
> Here too.

Done.

[falken, 2014-08-12 00:23:43]

Jeffrey, what do you think of this change? It looks reasonable to me but I'm not
so familiar with this code.

BTW, the latest tryjobs have DCHECK failures on the Service Worker layout tests.

[xiang, 2014-08-12 07:24:40]

On 2014/08/12 00:23:43, falken wrote:
> Jeffrey, what do you think of this change? It looks reasonable to me but I'm
not
> so familiar with this code.
> 
> BTW, the latest tryjobs have DCHECK failures on the Service Worker layout
tests.

The DCHECK fails when RPH calls AddObserver when the observer is already added.
This could happen when a RP registers multiple scopes.
As there's no HasObserver method for RPH, I fixed this by removing the observer
at first.

[kinuko, 2014-08-12 15:27:07]

DBC (warning: I've been away from the code for a while so I might be talking
based on stale design)

I vaguely remember that we had a plan to implement special SiteInstance creation
method (using special site URL etc) to reuse existing RPH whenever possible, and
get rid of possible_process_ids at all.  Is the plan still valid/feasible? If so
could we proceed in the direction as it sounded cleaner?

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
File content/browser/service_worker/service_worker_process_manager.cc (right):

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.cc:77: const GURL&
scope, const std::vector<int>& pending_processes) {
Looks like these methods are called only on IO thread, if so we should just
DCHECK the condition, remove the CurrentlyOn/PostTask code below and add a
comment in the header to note about the thread restriction.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
File content/browser/service_worker/service_worker_process_manager.h (right):

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.h:73: const
std::vector<int>& pending_processes);
This method and where we call it feels a bit sketchy to me (not your fault,
original design around pending_process_ids_ was also a bit awkward).  It looks
like when/where we want to call these methods are not necessarily in the
SWVersion code, but similar to when we associate SWPH to SW registrations (i.e.
1. when an in-scope document is loaded in SWControlleeRequestHandler, and 2.
when a new registration is about to be installed in SWRegisterJob)?  If so we
might be able to simply call these methods in SWPH::{Un,}assocRegistration and
remove Pending version of method, to simplify the model?

[kinuko, 2014-08-12 15:42:48]

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
File content/browser/service_worker/service_worker_process_manager.cc (right):

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.cc:77: const GURL&
scope, const std::vector<int>& pending_processes) {
On 2014/08/12 15:27:07, kinuko (slow to respond) wrote:
> Looks like these methods are called only on IO thread, if so we should just
> DCHECK the condition, remove the CurrentlyOn/PostTask code below and add a
> comment in the header to note about the thread restriction.

Oops, this comment was irrelevant, please ignore this particular one.

[Jeffrey Yasskin, 2014-08-19 23:42:24]

Sorry for missing this.

The special SiteInstance creation mode will take a lot of digging into Chrome's
process creation code, and it might turn out not to be feasible in the end. I'm
also not expecting to get time to do it. If this CL improves things, it probably
makes sense to take it even if the SiteInstance refactoring would be even
better.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
File content/browser/service_worker/service_worker_process_manager.cc (right):

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.cc:99: // FIXME:
the pending process maybe contained by multiple scopes, as
s/maybe/may be/

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.cc:100: // RPH
doesn't have "HasObserver" method, let's remove it first.
s/method, let's/method. Let's/

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.cc:122:
ProcessRefMap::iterator found = process_refs.find(process_id);
You can write these 4 lines as:

++process_refs[process_id];

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.cc:152: if
(--found->second == 0) {
You're not guarding against releasing a pending process reference.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.cc:217: if
(!sorted_candidates.empty()) {
You don't need to check this. If sorted_candidates is empty, the for loop won't
be entered anyway.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
File content/browser/service_worker/service_worker_process_manager.h (right):

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.h:70: // score
will be chosen to start worker. The pending processes will be added
It's not clear what a "score" or "priority" is here.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.h:73: const
std::vector<int>& pending_processes);
On 2014/08/12 15:27:07, kinuko (slow to respond) wrote:
> This method and where we call it feels a bit sketchy to me (not your fault,
> original design around pending_process_ids_ was also a bit awkward).  It looks
> like when/where we want to call these methods are not necessarily in the
> SWVersion code, but similar to when we associate SWPH to SW registrations
(i.e.
> 1. when an in-scope document is loaded in SWControlleeRequestHandler, and 2.
> when a new registration is about to be installed in SWRegisterJob)?  If so we
> might be able to simply call these methods in SWPH::{Un,}assocRegistration and
> remove Pending version of method, to simplify the model?

+1 to removing "pending" processes, if possible.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.h:104: typedef
std::map<int, int> ProcessRefMap;
Always document what an "int" means.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
File content/browser/service_worker/service_worker_process_manager_unittest.cc
(right):

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager_unittest.cc:17: :
thread_bundle_(TestBrowserThreadBundle::IO_MAINLOOP) {}
You may not need IO_MAINLOOP. BrowserThread::CurrentlyOn() will return true for
any argument given a TestBrowserThreadBundle with no REAL_X_THREAD arguments.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager_unittest.cc:59: //
Scores for processes 1, 2, 3  are not change, process 4's score is 0.
s/change/changed/

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
File content/browser/service_worker/service_worker_version.h (right):

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_version.h:125: //
|pause_after_download| is a flag to tell worker to pause after download.
This isn't a particularly useful comment. What would be useful is a statement of
how to unpause the worker and what steps of startup it pauses between.

[xiang, 2014-08-29 07:49:40]

Thanks for the review, please take another look!

I updated this CL, as it will benefit system resource consumption before
SiteInstance way be implemented.

Also per Yasskin@ and kinuko@'s suggestion, to simplify the model, pending
processes logic is removed from process manager. And SWPH will update the
process references instead of SWVersion.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
File content/browser/service_worker/service_worker_process_manager.cc (right):

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.cc:100: // RPH
doesn't have "HasObserver" method, let's remove it first.
On 2014/08/19 23:42:24, Jeffrey Yasskin wrote:
> s/method, let's/method. Let's/

this method is removed.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.cc:122:
ProcessRefMap::iterator found = process_refs.find(process_id);
On 2014/08/19 23:42:24, Jeffrey Yasskin wrote:
> You can write these 4 lines as:
> 
> ++process_refs[process_id];

Done.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.cc:152: if
(--found->second == 0) {
On 2014/08/19 23:42:23, Jeffrey Yasskin wrote:
> You're not guarding against releasing a pending process reference.

we don't have pending process now.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.cc:217: if
(!sorted_candidates.empty()) {
On 2014/08/19 23:42:23, Jeffrey Yasskin wrote:
> You don't need to check this. If sorted_candidates is empty, the for loop
won't
> be entered anyway.

Done.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
File content/browser/service_worker/service_worker_process_manager.h (right):

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.h:70: // score
will be chosen to start worker. The pending processes will be added
On 2014/08/19 23:42:24, Jeffrey Yasskin wrote:
> It's not clear what a "score" or "priority" is here.

Done.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.h:73: const
std::vector<int>& pending_processes);
On 2014/08/19 23:42:24, Jeffrey Yasskin wrote:
> On 2014/08/12 15:27:07, kinuko (slow to respond) wrote:
> > This method and where we call it feels a bit sketchy to me (not your fault,
> > original design around pending_process_ids_ was also a bit awkward).  It
looks
> > like when/where we want to call these methods are not necessarily in the
> > SWVersion code, but similar to when we associate SWPH to SW registrations
> (i.e.
> > 1. when an in-scope document is loaded in SWControlleeRequestHandler, and 2.
> > when a new registration is about to be installed in SWRegisterJob)?  If so
we
> > might be able to simply call these methods in SWPH::{Un,}assocRegistration
and
> > remove Pending version of method, to simplify the model?
> 
> +1 to removing "pending" processes, if possible. 

Done.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager.h:104: typedef
std::map<int, int> ProcessRefMap;
On 2014/08/19 23:42:24, Jeffrey Yasskin wrote:
> Always document what an "int" means.

Done.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
File content/browser/service_worker/service_worker_process_manager_unittest.cc
(right):

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager_unittest.cc:17: :
thread_bundle_(TestBrowserThreadBundle::IO_MAINLOOP) {}
On 2014/08/19 23:42:24, Jeffrey Yasskin wrote:
> You may not need IO_MAINLOOP. BrowserThread::CurrentlyOn() will return true
for
> any argument given a TestBrowserThreadBundle with no REAL_X_THREAD arguments.

Done.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_process_manager_unittest.cc:59: //
Scores for processes 1, 2, 3  are not change, process 4's score is 0.
On 2014/08/19 23:42:24, Jeffrey Yasskin wrote:
> s/change/changed/

this test is removed.

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
File content/browser/service_worker/service_worker_version.h (right):

https://codereview.chromium.org/443593002/diff/40001/content/browser/service_...
content/browser/service_worker/service_worker_version.h:125: //
|pause_after_download| is a flag to tell worker to pause after download.
On 2014/08/19 23:42:24, Jeffrey Yasskin wrote:
> This isn't a particularly useful comment. What would be useful is a statement
of
> how to unpause the worker and what steps of startup it pauses between.

Done.

[dominicc (has gone to gerrit), 2014-09-03 17:49:59]

This informally LGTM modulo a couple of nits inline. You will need OWNERS
review.

I think the refactoring makes sense: The process manager should manage sticking
Service Workers to processes. In particular it looks better to pass objects like
providers instead of process IDs everywhere.

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
File content/browser/service_worker/service_worker_handle_unittest.cc (right):

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_handle_unittest.cc:60: // Simulate
adding one process to the pattern.
Because of the method name, and this being one line, I don't think we need this
comment any more. The code tells the story.

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
File content/browser/service_worker/service_worker_provider_host.h (right):

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_provider_host.h:88: // Associates
to |registration| then this provider can provide running
This comment needs work.

[michaeln1, 2014-09-03 21:06:40]

> In particular it looks better to pass objects like providers instead of
process IDs

+millions

[michaeln, 2014-09-04 01:26:33]

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
File content/browser/service_worker/service_worker_provider_host.h (right):

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_provider_host.h:147:
std::vector<scoped_refptr<ServiceWorkerRegistration> > pending_registrations_;
can this be a collection of GURL patterns so this book keeping does not affect
the swregistration object lifetimes?

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
File content/browser/service_worker/service_worker_register_job.cc (right):

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_register_job.cc:67:
pending_provider_hosts_.push_back(provider_host->AsWeakPtr());
Why defer till later? Maybe we don't need the pending collection at all.

provider_host->AddScopedProcessReferenceToPattern(pattern_)

[michaeln, 2014-09-04 01:31:13]

I'll ask Jeffrey to take another look.

> provider_host->AddScopedProcessReferenceToPattern(pattern_)

Using 'ProcessReferenceToPattern' in this method name would help to let readers
understand the relationship to methods elsewhere with names along those lines.

[xiang, 2014-09-04 09:18:37]

Thanks for the review. CL updated, PTAL.

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
File content/browser/service_worker/service_worker_handle_unittest.cc (right):

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_handle_unittest.cc:60: // Simulate
adding one process to the pattern.
On 2014/09/03 17:49:59, dominicc--slow until 9.9 wrote:
> Because of the method name, and this being one line, I don't think we need
this
> comment any more. The code tells the story.

Done.

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
File content/browser/service_worker/service_worker_provider_host.h (right):

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_provider_host.h:88: // Associates
to |registration| then this provider can provide running
On 2014/09/03 17:49:59, dominicc--slow until 9.9 wrote:
> This comment needs work.

Done.

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_provider_host.h:147:
std::vector<scoped_refptr<ServiceWorkerRegistration> > pending_registrations_;
On 2014/09/04 01:26:32, michaeln wrote:
> can this be a collection of GURL patterns so this book keeping does not affect
> the swregistration object lifetimes?

Done.

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
File content/browser/service_worker/service_worker_register_job.cc (right):

https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
content/browser/service_worker/service_worker_register_job.cc:67:
pending_provider_hosts_.push_back(provider_host->AsWeakPtr());
On 2014/09/04 01:26:32, michaeln wrote:
> Why defer till later? Maybe we don't need the pending collection at all.
> 
> provider_host->AddScopedProcessReferenceToPattern(pattern_)

Yes, you're right, we don't need to pend it anymore.
However SWPH still need to distinguish register callback pattern and associated
registration pattern, So I added AssociatePattern method to SWPH, and used it
here instead.

[xiang, 2014-09-04 12:11:24]

>
https://codereview.chromium.org/443593002/diff/60001/content/browser/service_...
> content/browser/service_worker/service_worker_register_job.cc:67:
> pending_provider_hosts_.push_back(provider_host->AsWeakPtr());
> On 2014/09/04 01:26:32, michaeln wrote:
> > Why defer till later? Maybe we don't need the pending collection at all.
> > 
> > provider_host->AddScopedProcessReferenceToPattern(pattern_)
> 
> Yes, you're right, we don't need to pend it anymore.
> However SWPH still need to distinguish register callback pattern and
associated
> registration pattern, So I added AssociatePattern method to SWPH, and used it
> here instead.

Oops, I misunderstood it, please ignore the reply.

[michaeln, 2014-09-05 00:50:12]

lgtm

[kinuko, 2014-09-08 08:07:48]

Fyi, this lgtm 2.

[xiang, 2014-09-09 07:17:21]

The CQ bit was checked by xiang.long@intel.com

[commit-bot: I haz the power, 2014-09-09 07:19:17]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/xiang.long@intel.com/443593002/120001

[commit-bot: I haz the power, 2014-09-09 08:09:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-09 08:09:23]

Try jobs failed on following builders:
  linux_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu/builds/...)
  mac_gpu on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/mac_gpu/builds/53286)
  android_arm64_dbg_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_arm64_d...)
  android_dbg_tests_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tes...)
  mac_chromium_rel_swarming on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
  win_chromium_x64_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[xiang, 2014-09-09 08:48:43]

The CQ bit was checked by xiang.long@intel.com

[commit-bot: I haz the power, 2014-09-09 08:49:35]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/xiang.long@intel.com/443593002/140001

[commit-bot: I haz the power, 2014-09-09 09:17:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-09 09:17:27]

Try jobs failed on following builders:
  android_arm64_dbg_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_arm64_d...)
  android_clang_dbg_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_clang_d...)
  android_dbg_tests_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tes...)
  linux_chromium_chromeos_rel_swarming on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_swarming on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_compile_dbg on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_swarming on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
  win8_chromium_rel on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_rel...)
  win_chromium_compile_dbg on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)
  win_chromium_x64_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[xiang, 2014-09-10 04:39:28]

The CQ bit was checked by xiang.long@intel.com

[commit-bot: I haz the power, 2014-09-10 04:40:17]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/xiang.long@intel.com/443593002/160001

[commit-bot: I haz the power, 2014-09-10 05:48:14]

Committed patchset #9 (id:160001) as c4b04204bc1637995dd6494b3a73f9eda6329cd8

[commit-bot: I haz the power, 2014-09-10 05:50:05]

Patchset 9 (id:??) landed as
https://crrev.com/3c4d6ceb7f29eaa4024bfe268e033a2ea296066b
Cr-Commit-Position: refs/heads/master@{#294113}