predictors: Introduce GlowplugPredictor.

predictors: Introduce LoadingPredictor.

This is the first step of the Glowplug refactoring. It extracts the
external entry points of Glowplug, and starts to separate the resource
prefetch specific parts from the rest.

This CL mostly adds the top-level Glowplug classes, and there is no
behavior change. This will make further refactoring easier. The Android
side client code will be updated in a forthcoming CL.

BUG=715525
Review-Url: https://codereview.chromium.org/2847183002
Cr-Commit-Position: refs/heads/master@{#471718}
Committed: https://chromium.googlesource.com/chromium/src/+/d999f0f298065398ec9bbc156c177892d74d17f6

[Benoit L, 2017-04-28 15:43:36]

The CQ bit was checked by lizeb@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-28 15:44:25]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-28 17:23:22]

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

[commit-bot: I haz the power, 2017-04-28 17:23:23]

Dry run: Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[Benoit L, 2017-05-10 12:10:45]

The CQ bit was checked by lizeb@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-10 12:11:28]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-10 13:21:57]

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

[commit-bot: I haz the power, 2017-05-10 13:21:58]

Dry run: Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[Benoit L, 2017-05-11 12:31:22]

The CQ bit was checked by lizeb@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-11 12:32:16]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Benoit L, 2017-05-11 12:43:10]

The CQ bit was checked by lizeb@chromium.org to run a CQ dry run

[Benoit L, 2017-05-11 12:43:22]

lizeb@chromium.org changed reviewers:
+ alexilin@chromium.org

[commit-bot: I haz the power, 2017-05-11 12:43:44]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-11 14:28:16]

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

[commit-bot: I haz the power, 2017-05-11 14:28:17]

Dry run: This issue passed the CQ dry run.

[alexilin, 2017-05-11 16:53:12]

Thanks!

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
File chrome/browser/predictors/glowplug_config.h (right):

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_config.h:23: struct GlowplugPredictorConfig {
I don't see clear benefits of moving it outside of resource_prefetch_common.
What is the goal here?

Do we want to have one big config for the whole glowplug or separate configs for
each component?

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
File chrome/browser/predictors/glowplug_predictor.cc (right):

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_predictor.cc:14: resource_prefetch_predictor_
= base::WrapUnique<ResourcePrefetchPredictor>(
nit: why not MakeUnique?

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
File chrome/browser/predictors/glowplug_predictor.h (right):

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_predictor.h:21: // All methods must be called
from the UI thread.
Shouldn't we have here a detailed description of the Glowplug since it's an
entry point?

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_predictor.h:30: void StartPrefetching(const
GURL& main_frame_url, PrefetchOrigin origin);
Do you want to keep this function name? I think now is the best moment to rename
it as you wanted.

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_predictor.h:35: ResourcePrefetchPredictor*
resource_prefetch_predictor() const;
As I understand, it's temporary for clients who will use data collection
interface after refactoring, right?

Currently I see a problem that users of GlowplugPredictor could keep using raw
pointer after GlowplugPredictor destruction.

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
File chrome/browser/predictors/glowplug_predictor_factory.cc (right):

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_predictor_factory.cc:18: GlowplugPredictor*
GlowplugPredictorFactory::GetForProfile(
Shouldn't we rename it to GetForBrowserContext?

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
File chrome/browser/predictors/resource_prefetch_common.h (right):

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/resource_prefetch_common.h:41: // Returns true if
prefetching is enabled. And will initilize the |config|
Could you add a comment that a config could be null?

/initilize/initialize

[Benoit L, 2017-05-12 12:12:32]

The CQ bit was checked by lizeb@chromium.org to run a CQ dry run

[Benoit L, 2017-05-12 12:12:53]

Thanks!
All done.

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
File chrome/browser/predictors/glowplug_config.h (right):

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_config.h:23: struct GlowplugPredictorConfig {
On 2017/05/11 16:53:12, alexilin wrote:
> I don't see clear benefits of moving it outside of resource_prefetch_common.
> What is the goal here?
> 
> Do we want to have one big config for the whole glowplug or separate configs
for
> each component?

The goal is to have a global object to configure glowplug, with members for the
various components. Part of the config will be shared, for instance  how many
hosts to keep, confidence levels, etc. So it makes sense to have a
glowplug-level config, containing everything for now.

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
File chrome/browser/predictors/glowplug_predictor.cc (right):

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_predictor.cc:14: resource_prefetch_predictor_
= base::WrapUnique<ResourcePrefetchPredictor>(
On 2017/05/11 16:53:12, alexilin wrote:
> nit: why not MakeUnique?

No good reason, used that to make ResourcePrefetchPredictor constructor private
during iteration.

Done.

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
File chrome/browser/predictors/glowplug_predictor.h (right):

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_predictor.h:21: // All methods must be called
from the UI thread.
On 2017/05/11 16:53:12, alexilin wrote:
> Shouldn't we have here a detailed description of the Glowplug since it's an
> entry point? 

Done.

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_predictor.h:30: void StartPrefetching(const
GURL& main_frame_url, PrefetchOrigin origin);
On 2017/05/11 16:53:12, alexilin wrote:
> Do you want to keep this function name? I think now is the best moment to
rename
> it as you wanted.

Done.

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_predictor.h:35: ResourcePrefetchPredictor*
resource_prefetch_predictor() const;
On 2017/05/11 16:53:12, alexilin wrote:
> As I understand, it's temporary for clients who will use data collection
> interface after refactoring, right?
> 
> Currently I see a problem that users of GlowplugPredictor could keep using raw
> pointer after GlowplugPredictor destruction.

Yes, it's temporary. Added a comment.
Getting a raw pointer doesn't imply ownership. And the lifetime of it is tied to
the lifetime of GlowplugPredictor, so clients are fine.

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
File chrome/browser/predictors/glowplug_predictor_factory.cc (right):

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_predictor_factory.cc:18: GlowplugPredictor*
GlowplugPredictorFactory::GetForProfile(
On 2017/05/11 16:53:12, alexilin wrote:
> Shouldn't we rename it to GetForBrowserContext?

It seems that there is no consistent convention in the code base, with
GetForProfile() taking either a profile or a BrowserContext...
And also quite a few GetForBrowserContext().

Changed the parameter to Profile.

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
File chrome/browser/predictors/resource_prefetch_common.h (right):

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/resource_prefetch_common.h:41: // Returns true if
prefetching is enabled. And will initilize the |config|
On 2017/05/11 16:53:12, alexilin wrote:
> Could you add a comment that a config could be null?
> 
> /initilize/initialize

Done.

[commit-bot: I haz the power, 2017-05-12 12:12:58]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-12 13:13:15]

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

[commit-bot: I haz the power, 2017-05-12 13:13:16]

Dry run: This issue passed the CQ dry run.

[alexilin, 2017-05-12 14:26:46]

Thank you Benoit for doing this unpleasant job!
lgtm with nits.

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
File chrome/browser/predictors/glowplug_config.h (right):

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_config.h:23: struct GlowplugPredictorConfig {
On 2017/05/12 12:12:52, Benoit L wrote:
> On 2017/05/11 16:53:12, alexilin wrote:
> > I don't see clear benefits of moving it outside of resource_prefetch_common.
> > What is the goal here?
> > 
> > Do we want to have one big config for the whole glowplug or separate configs
> for
> > each component?
> 
> The goal is to have a global object to configure glowplug, with members for
the
> various components. Part of the config will be shared, for instance  how many
> hosts to keep, confidence levels, etc. So it makes sense to have a
> glowplug-level config, containing everything for now.

Cool, makes sense. Thanks!

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
File chrome/browser/predictors/glowplug_predictor.h (right):

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_predictor.h:35: ResourcePrefetchPredictor*
resource_prefetch_predictor() const;
On 2017/05/12 12:12:52, Benoit L wrote:
> On 2017/05/11 16:53:12, alexilin wrote:
> > As I understand, it's temporary for clients who will use data collection
> > interface after refactoring, right?
> > 
> > Currently I see a problem that users of GlowplugPredictor could keep using
raw
> > pointer after GlowplugPredictor destruction.
> 
> Yes, it's temporary. Added a comment.
> Getting a raw pointer doesn't imply ownership. And the lifetime of it is tied
to
> the lifetime of GlowplugPredictor, so clients are fine.

Clients could outlive GlowplugPredictor while keeping the pointer and
accidentally use it after GlowplugPredictor destruction. Though, it would mean
that a client uses GlowplugPredictor without explicitly declaring dependency on
it, that's bad.

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
File chrome/browser/predictors/glowplug_config.h (right):

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
chrome/browser/predictors/glowplug_config.h:16: // Returns whether glowplug is
enabled, and populate |config|, if not nullptr.
nit:
/populate/populates

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
File chrome/browser/predictors/glowplug_predictor.h (right):

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
chrome/browser/predictors/glowplug_predictor.h:45: // KeyedService methods
override.
silly nit:
/KeyedService methods override./KeyedService:

My point is it would be nice to use the same style for marking overrides. During
refactoring, we could converge :)

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
File chrome/browser/predictors/glowplug_predictor_factory.h (right):

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
chrome/browser/predictors/glowplug_predictor_factory.h:29: //
RefcountedBrowserContextKeyedServiceFactory:
nit:
/RefcountedBrowserContextKeyedServiceFactory/BrowserContextKeyedServiceFactory

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
File chrome/browser/predictors/predictor_database.cc (right):

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
chrome/browser/predictors/predictor_database.cc:7: #include <stdint.h>
nit:
/stdint.h/cstdint
and get rid of empty line?

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
File chrome/browser/predictors/resource_prefetch_common.cc (right):

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
chrome/browser/predictors/resource_prefetch_common.cc:37: bool
IsPrefetchingEnabledInternal(Profile* profile, int mode, int mask) {
Why don't move it to glowplug_config.cc?
The only callers of this method IsPrefetchingEnabledForSomeOrigin() and
IsPrefetchingEnabledForOrigin() are located there.

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
File chrome/browser/predictors/resource_prefetch_predictor.h (right):

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
chrome/browser/predictors/resource_prefetch_predictor.h:272: friend class
MockResourcePrefetchPredictor;
Do we really need this friend?

[Benoit L, 2017-05-12 15:13:10]

lizeb@chromium.org changed reviewers:
+ avi@chromium.org, csharrison@chromium.org, msarda@chromium.org

[Benoit L, 2017-05-12 15:13:12]

Thanks!

For new reviewers: welcome! This is just a refactoring / renaming, hence the
large diff. Can you take a look at:

+msarda: chrome/browser/profiles/
+csharrison: chrome/browser/page_load_metrics/
+avi: tab_helpers

Thanks!

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
File chrome/browser/predictors/glowplug_predictor.h (right):

https://codereview.chromium.org/2847183002/diff/80001/chrome/browser/predicto...
chrome/browser/predictors/glowplug_predictor.h:35: ResourcePrefetchPredictor*
resource_prefetch_predictor() const;
On 2017/05/12 14:26:45, alexilin wrote:
> On 2017/05/12 12:12:52, Benoit L wrote:
> > On 2017/05/11 16:53:12, alexilin wrote:
> > > As I understand, it's temporary for clients who will use data collection
> > > interface after refactoring, right?
> > > 
> > > Currently I see a problem that users of GlowplugPredictor could keep using
> raw
> > > pointer after GlowplugPredictor destruction.
> > 
> > Yes, it's temporary. Added a comment.
> > Getting a raw pointer doesn't imply ownership. And the lifetime of it is
tied
> to
> > the lifetime of GlowplugPredictor, so clients are fine.
> 
> Clients could outlive GlowplugPredictor while keeping the pointer and
> accidentally use it after GlowplugPredictor destruction. Though, it would mean
> that a client uses GlowplugPredictor without explicitly declaring dependency
on
> it, that's bad.

Per offline discussion, no issues here, since the only client caching the
pointer declares the dependency.

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
File chrome/browser/predictors/glowplug_config.h (right):

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
chrome/browser/predictors/glowplug_config.h:16: // Returns whether glowplug is
enabled, and populate |config|, if not nullptr.
On 2017/05/12 14:26:45, alexilin wrote:
> nit:
> /populate/populates

Done.

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
File chrome/browser/predictors/glowplug_predictor.h (right):

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
chrome/browser/predictors/glowplug_predictor.h:45: // KeyedService methods
override.
On 2017/05/12 14:26:45, alexilin wrote:
> silly nit:
> /KeyedService methods override./KeyedService:
> 
> My point is it would be nice to use the same style for marking overrides.
During
> refactoring, we could converge :)

Done.

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
File chrome/browser/predictors/glowplug_predictor_factory.h (right):

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
chrome/browser/predictors/glowplug_predictor_factory.h:29: //
RefcountedBrowserContextKeyedServiceFactory:
On 2017/05/12 14:26:45, alexilin wrote:
> nit:
> /RefcountedBrowserContextKeyedServiceFactory/BrowserContextKeyedServiceFactory

Done.

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
File chrome/browser/predictors/predictor_database.cc (right):

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
chrome/browser/predictors/predictor_database.cc:7: #include <stdint.h>
On 2017/05/12 14:26:46, alexilin wrote:
> nit:
> /stdint.h/cstdint
> and get rid of empty line?

Done.

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
File chrome/browser/predictors/resource_prefetch_predictor.h (right):

https://codereview.chromium.org/2847183002/diff/100001/chrome/browser/predict...
chrome/browser/predictors/resource_prefetch_predictor.h:272: friend class
MockResourcePrefetchPredictor;
On 2017/05/12 14:26:46, alexilin wrote:
> Do we really need this friend?

Oops.
No friend is best friend!
Hum... not sure about that one.

Done.

[Benoit L, 2017-05-12 15:13:22]

The CQ bit was checked by lizeb@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-12 15:14:07]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[msarda, 2017-05-12 15:16:51]

//chrome/browser/profiles/ LGTM.

[Charlie Harrison, 2017-05-12 15:22:09]

page_load_metrics LGTM but maybe you could make the comment in
glowplug_predictor.h a bit more prominent or add a readme explaining what
glowplug is? I would be pretty confused seeing that if I didn't already know
about the project :)

[Avi (use Gerrit), 2017-05-12 15:31:22]

On 2017/05/12 15:22:09, Charlie Harrison wrote:
> page_load_metrics LGTM but maybe you could make the comment in
> glowplug_predictor.h a bit more prominent or add a readme explaining what
> glowplug is? I would be pretty confused seeing that if I didn't already know
> about the project :)

Honestly, not lgtm because of that.

Names need to be descriptive of what the code does, so that someone looking
around can orient themselves and get a sense of what the pieces do. Using
codenames adds a barrier to entry to working on the code, something that you
have to know to have a chance. Chromium is complicated enough; let's stick with
simple, descriptive, plain-English names for things.

[Charlie Harrison, 2017-05-12 15:42:02]

On 2017/05/12 15:31:22, Avi (ping after 24h) wrote:
> On 2017/05/12 15:22:09, Charlie Harrison wrote:
> > page_load_metrics LGTM but maybe you could make the comment in
> > glowplug_predictor.h a bit more prominent or add a readme explaining what
> > glowplug is? I would be pretty confused seeing that if I didn't already know
> > about the project :)
> 
> Honestly, not lgtm because of that.
> 
> Names need to be descriptive of what the code does, so that someone looking
> around can orient themselves and get a sense of what the pieces do. Using
> codenames adds a barrier to entry to working on the code, something that you
> have to know to have a chance. Chromium is complicated enough; let's stick
with
> simple, descriptive, plain-English names for things.

This makes sense to me, and I would +1 a rename that is more semantic.

[commit-bot: I haz the power, 2017-05-12 16:15:49]

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

[commit-bot: I haz the power, 2017-05-12 16:15:50]

Dry run: This issue passed the CQ dry run.

[Benoit L, 2017-05-12 16:28:14]

Description was changed from

==========
predictors: Introduce GlowplugPredictor.

This is the first step of the Glowplug refactoring. It extracts the
external entry points of Glowplug, and starts to separate the resource
prefetch specific parts from the rest.

This CL mostly adds the top-level Glowplug classes, and there is no
behavior change. This will make further refactoring easier. The Android
side client code will be updated in a forthcoming CL.

BUG=715525
==========

to

==========
predictors: Introduce LoadingPredictor.

This is the first step of the Glowplug refactoring. It extracts the
external entry points of Glowplug, and starts to separate the resource
prefetch specific parts from the rest.

This CL mostly adds the top-level Glowplug classes, and there is no
behavior change. This will make further refactoring easier. The Android
side client code will be updated in a forthcoming CL.

BUG=715525
==========

[Benoit L, 2017-05-12 16:36:48]

The CQ bit was checked by lizeb@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-12 16:37:36]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Benoit L, 2017-05-12 16:40:16]

Thanks for the comments, you're right.
Renamed to LoadingPredictor, since from the high-level comment in
LoadingPredictor:

// From a high-level request (GURL and motivation) and a database of historical
// data, initiates predictive actions to speed up page loads.

[Avi (use Gerrit), 2017-05-12 17:01:39]

lgtm for both the rename and tab_helpers

[Charlie Harrison, 2017-05-12 17:09:26]

plm still lgtm

[commit-bot: I haz the power, 2017-05-12 18:12:08]

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

[commit-bot: I haz the power, 2017-05-12 18:12:09]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Benoit L, 2017-05-15 08:29:39]

The CQ bit was checked by lizeb@chromium.org

[Benoit L, 2017-05-15 08:29:39]

The patchset sent to the CQ was uploaded after l-g-t-m from
alexilin@chromium.org, msarda@chromium.org
Link to the patchset: https://codereview.chromium.org/2847183002/#ps140001
(title: "GlowplugPredictor -> LoadingPredictor")

[commit-bot: I haz the power, 2017-05-15 08:29:57]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-15 10:23:59]

CQ is committing da patch.

Bot data: {"patchset_id": 140001, "attempt_start_ts": 1494836979076890,
"parent_rev": "6e6b3251a1e8291b81058d51d168f8ce377b8eb3", "commit_rev":
"d999f0f298065398ec9bbc156c177892d74d17f6"}

[commit-bot: I haz the power, 2017-05-15 10:24:09]

Description was changed from

==========
predictors: Introduce LoadingPredictor.

This is the first step of the Glowplug refactoring. It extracts the
external entry points of Glowplug, and starts to separate the resource
prefetch specific parts from the rest.

This CL mostly adds the top-level Glowplug classes, and there is no
behavior change. This will make further refactoring easier. The Android
side client code will be updated in a forthcoming CL.

BUG=715525
==========

to

==========
predictors: Introduce LoadingPredictor.

This is the first step of the Glowplug refactoring. It extracts the
external entry points of Glowplug, and starts to separate the resource
prefetch specific parts from the rest.

This CL mostly adds the top-level Glowplug classes, and there is no
behavior change. This will make further refactoring easier. The Android
side client code will be updated in a forthcoming CL.

BUG=715525

Review-Url: https://codereview.chromium.org/2847183002
Cr-Commit-Position: refs/heads/master@{#471718}
Committed:
https://chromium.googlesource.com/chromium/src/+/d999f0f298065398ec9bbc156c17...
==========

[commit-bot: I haz the power, 2017-05-15 10:24:11]

Committed patchset #8 (id:140001) as
https://chromium.googlesource.com/chromium/src/+/d999f0f298065398ec9bbc156c17...