Move memory_coordinator_client and its registry to base/memory

Move memory_coordinator_client and its registry to base/memory

This is the first CL to move memory_coordinator outside components/.
Also, per discussion on [1], this CL removes MemoryCoordinatorClient
from HistoryBackend. We can re-add it if needed.

[1] https://codereview.chromium.org/2297243004/#msg14

BUG=644022
Committed: https://crrev.com/e70150fb5845bf645adec87036eca3b789d7ddcc
Cr-Commit-Position: refs/heads/master@{#418766}

[bashi, 2016-09-05 01:50:58]

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

[commit-bot: I haz the power, 2016-09-05 01:51:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[bashi, 2016-09-05 01:51:43]

Description was changed from

==========
Move memory_coordinator_client and its registry to base/memory

This is the first CL to move memory_coordinator outside components/.
Also, per discussion on [1], this CL removes MemoryCoordinatorClient
from HistoryBackend. We can re-add t if needed.

[1] https://codereview.chromium.org/2297243004/#msg14

BUG=644022
==========

to

==========
Move memory_coordinator_client and its registry to base/memory

This is the first CL to move memory_coordinator outside components/.
Also, per discussion on [1], this CL removes MemoryCoordinatorClient
from HistoryBackend. We can re-add it if needed.

[1] https://codereview.chromium.org/2297243004/#msg14

BUG=644022
==========

[bashi, 2016-09-05 02:48:18]

bashi@chromium.org changed reviewers:
+ chrisha@chromium.org, haraken@chromium.org, sky@chromium.org,
tasak@google.com, thakis@chromium.org

[bashi, 2016-09-05 02:48:19]

Hi OWNERS,

Could you review this?

thakis@: base
haraken@, chrisha@: components/memory_coordinator
sky@: components/history

tasak@: FYI

[commit-bot: I haz the power, 2016-09-05 03:07:10]

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

[commit-bot: I haz the power, 2016-09-05 03:07:11]

Dry run: This issue passed the CQ dry run.

[haraken, 2016-09-05 04:18:12]

LGTM

[tasak, 2016-09-05 07:47:07]

lgtm

[haraken, 2016-09-06 07:49:21]

The CQ bit was checked by haraken@chromium.org

[haraken, 2016-09-06 07:49:26]

The CQ bit was unchecked by haraken@chromium.org

[chrisha, 2016-09-06 13:23:18]

lgtm

[sky, 2016-09-06 20:21:11]

https://codereview.chromium.org/2311723002/diff/1/components/history/core/bro...
File components/history/core/browser/history_backend.cc (right):

https://codereview.chromium.org/2311723002/diff/1/components/history/core/bro...
components/history/core/browser/history_backend.cc:740: void
HistoryBackend::TrimMemory(bool trim_aggressively) {
How that there is only one call to TrimMemory, can you move the implementation
to the call site?

[bashi, 2016-09-07 23:22:56]

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

[commit-bot: I haz the power, 2016-09-07 23:23:50]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[bashi, 2016-09-07 23:38:35]

https://codereview.chromium.org/2311723002/diff/1/components/history/core/bro...
File components/history/core/browser/history_backend.cc (right):

https://codereview.chromium.org/2311723002/diff/1/components/history/core/bro...
components/history/core/browser/history_backend.cc:740: void
HistoryBackend::TrimMemory(bool trim_aggressively) {
On 2016/09/06 20:21:11, sky wrote:
> How that there is only one call to TrimMemory, can you move the implementation
> to the call site?

Done.

[haraken, 2016-09-07 23:44:59]

Nico: Would you take a look at base/?

[commit-bot: I haz the power, 2016-09-08 01:05:52]

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

[commit-bot: I haz the power, 2016-09-08 01:05:54]

Dry run: This issue passed the CQ dry run.

[sky, 2016-09-08 04:17:39]

Thanks, LGTM

[bashi, 2016-09-08 06:22:34]

bashi@chromium.org changed reviewers:
+ dcheng@chromium.org

[bashi, 2016-09-08 06:22:34]

dcheng@: Could you review base/ ?

The motivation is described in
https://docs.google.com/document/d/1aURKosRD5uxw4LEEF1s6G3uR02qBv_19COfSXrtyJ...

[dcheng, 2016-09-08 21:28:26]

https://codereview.chromium.org/2311723002/diff/20001/base/memory/memory_coor...
File base/memory/memory_coordinator_client_registry.cc (right):

https://codereview.chromium.org/2311723002/diff/20001/base/memory/memory_coor...
base/memory/memory_coordinator_client_registry.cc:18: : clients_(new ClientList)
{}
Why do we need to store this in a scoped_refptr?

[bashi, 2016-09-08 23:00:08]

https://codereview.chromium.org/2311723002/diff/20001/base/memory/memory_coor...
File base/memory/memory_coordinator_client_registry.cc (right):

https://codereview.chromium.org/2311723002/diff/20001/base/memory/memory_coor...
base/memory/memory_coordinator_client_registry.cc:18: : clients_(new ClientList)
{}
On 2016/09/08 21:28:26, dcheng wrote:
> Why do we need to store this in a scoped_refptr?

ObserverListThreadSafe is RefCountedThreadSafe. Can we put it in unique_ptr?

[dcheng, 2016-09-09 03:02:04]

https://codereview.chromium.org/2311723002/diff/20001/base/memory/memory_coor...
File base/memory/memory_coordinator_client.h (right):

https://codereview.chromium.org/2311723002/diff/20001/base/memory/memory_coor...
base/memory/memory_coordinator_client.h:15: THROTTLED = 1,
Please add some comments to these enums (I'm not sure what a throttled memory
state is, I would expect throttled to be a concept that applies to cpus)

https://codereview.chromium.org/2311723002/diff/20001/base/memory/memory_coor...
File base/memory/memory_coordinator_client_registry.cc (right):

https://codereview.chromium.org/2311723002/diff/20001/base/memory/memory_coor...
base/memory/memory_coordinator_client_registry.cc:18: : clients_(new ClientList)
{}
On 2016/09/08 23:00:08, bashi1 wrote:
> On 2016/09/08 21:28:26, dcheng wrote:
> > Why do we need to store this in a scoped_refptr?
> 
> ObserverListThreadSafe is RefCountedThreadSafe. Can we put it in unique_ptr?

Ah, I see... it's thread-safe so it can PostTask and do cross-thread
notifications.

[bashi, 2016-09-09 03:21:43]

https://codereview.chromium.org/2311723002/diff/20001/base/memory/memory_coor...
File base/memory/memory_coordinator_client.h (right):

https://codereview.chromium.org/2311723002/diff/20001/base/memory/memory_coor...
base/memory/memory_coordinator_client.h:15: THROTTLED = 1,
On 2016/09/09 03:02:04, dcheng wrote:
> Please add some comments to these enums (I'm not sure what a throttled memory
> state is, I would expect throttled to be a concept that applies to cpus)

Done.

[Nico, 2016-09-09 14:50:37]

thakis@chromium.org changed reviewers:
+ danakj@chromium.org
- thakis@chromium.org

[Nico, 2016-09-09 14:50:38]

danakj has been doing a lot of discussions about what stuff should go where. In
the past, I think the guideline was "if in doubt, components/", but the linked
bug suggests that that's no longer true. I don't want some ~random subset of
stuff moving into base, so I'm hoping there's some plan to prevent that --
danakj, do you know the story here?

(Maybe dcheng knows too; I don't.)

[chrisha, 2016-09-09 15:13:01]

On 2016/09/09 14:50:38, Nico wrote:
> danakj has been doing a lot of discussions about what stuff should go where.
In
> the past, I think the guideline was "if in doubt, components/", but the linked
> bug suggests that that's no longer true. I don't want some ~random subset of
> stuff moving into base, so I'm hoping there's some plan to prevent that --
> danakj, do you know the story here?
> 
> (Maybe dcheng knows too; I don't.)

We originally planned on being a component, but ran into a few roadblocks.
Namely, we have clients in 'net', and they can't depend on components but can
depend on base. We've tried to make as narrow as possible the part of the system
that lives in base (basically an interface definition and a client registry),
with the vast majority of logic living in content.

The linked bug and doc doesn't contain the full backstory. More details
available here:

https://codereview.chromium.org/2259743002/

...and in an email thread with Jochen.

[danakj, 2016-09-09 18:32:36]

On Fri, Sep 9, 2016 at 8:13 AM, <chrisha@chromium.org> wrote:

> On 2016/09/09 14:50:38, Nico wrote:
> > danakj has been doing a lot of discussions about what stuff should go
> where.
> In
> > the past, I think the guideline was "if in doubt, components/", but the
> linked
> > bug suggests that that's no longer true. I don't want some ~random
> subset of
> > stuff moving into base, so I'm hoping there's some plan to prevent that
> --
> > danakj, do you know the story here?
> >
> > (Maybe dcheng knows too; I don't.)
>
> We originally planned on being a component, but ran into a few roadblocks.
> Namely, we have clients in 'net', and they can't depend on components but
> can
> depend on base.
>

Every component is individual, so it can depend on your component without
depending on the rest, no?


> We've tried to make as narrow as possible the part of the system
> that lives in base (basically an interface definition and a client
> registry),
> with the vast majority of logic living in content.
>
> The linked bug and doc doesn't contain the full backstory. More details
> available here:
>
> https://codereview.chromium.org/2259743002/
>
> ...and in an email thread with Jochen.
>
> https://codereview.chromium.org/2311723002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[danakj, 2016-09-09 18:38:56]

On Fri, Sep 9, 2016 at 11:32 AM, <danakj@chromium.org> wrote:

> On Fri, Sep 9, 2016 at 8:13 AM, <chrisha@chromium.org> wrote:
>
>> On 2016/09/09 14:50:38, Nico wrote:
>> > danakj has been doing a lot of discussions about what stuff should go
>> where.
>> In
>> > the past, I think the guideline was "if in doubt, components/", but the
>> linked
>> > bug suggests that that's no longer true. I don't want some ~random
>> subset of
>> > stuff moving into base, so I'm hoping there's some plan to prevent that
>> --
>> > danakj, do you know the story here?
>> >
>> > (Maybe dcheng knows too; I don't.)
>>
>> We originally planned on being a component, but ran into a few roadblocks.
>> Namely, we have clients in 'net', and they can't depend on components but
>> can
>> depend on base.
>>
>
> Every component is individual, so it can depend on your component without
> depending on the rest, no?
>


>
>
>> We've tried to make as narrow as possible the part of the system
>> that lives in base (basically an interface definition and a client
>> registry),
>> with the vast majority of logic living in content.
>>
>> The linked bug and doc doesn't contain the full backstory. More details
>> available here:
>>
>> https://codereview.chromium.org/2259743002/
>>
>
The only context I can really see in there is that people wanted content/
but that won't make sense cuz net/ uses it, but then jochen says:

"offline discussion revealed that net/ is supposed to depend on this, so we
can't move the code either to content/ nor components/, but need to find a
new place. I suggested base/"

But I as above, I don't get why net/ can't depend on a single component. It
doesn't have to depend on them all. [+agl@chromium.org] from net/ can you
help?


>
>>
>> ...and in an email thread with Jochen.
>>
>> https://codereview.chromium.org/2311723002/
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[dcheng, 2016-09-09 18:45:53]

On 2016/09/09 18:38:56, danakj wrote:
> On Fri, Sep 9, 2016 at 11:32 AM, <mailto:danakj@chromium.org> wrote:
> 
> > On Fri, Sep 9, 2016 at 8:13 AM, <mailto:chrisha@chromium.org> wrote:
> >
> >> On 2016/09/09 14:50:38, Nico wrote:
> >> > danakj has been doing a lot of discussions about what stuff should go
> >> where.
> >> In
> >> > the past, I think the guideline was "if in doubt, components/", but the
> >> linked
> >> > bug suggests that that's no longer true. I don't want some ~random
> >> subset of
> >> > stuff moving into base, so I'm hoping there's some plan to prevent that
> >> --
> >> > danakj, do you know the story here?
> >> >
> >> > (Maybe dcheng knows too; I don't.)
> >>
> >> We originally planned on being a component, but ran into a few roadblocks.
> >> Namely, we have clients in 'net', and they can't depend on components but
> >> can
> >> depend on base.
> >>
> >
> > Every component is individual, so it can depend on your component without
> > depending on the rest, no?
> >
> 
> 
> >
> >
> >> We've tried to make as narrow as possible the part of the system
> >> that lives in base (basically an interface definition and a client
> >> registry),
> >> with the vast majority of logic living in content.
> >>
> >> The linked bug and doc doesn't contain the full backstory. More details
> >> available here:
> >>
> >> https://codereview.chromium.org/2259743002/
> >>
> >
> The only context I can really see in there is that people wanted content/
> but that won't make sense cuz net/ uses it, but then jochen says:
> 
> "offline discussion revealed that net/ is supposed to depend on this, so we
> can't move the code either to content/ nor components/, but need to find a
> new place. I suggested base/"
> 
> But I as above, I don't get why net/ can't depend on a single component. It
> doesn't have to depend on them all. mailto:[+agl@chromium.org] from net/ can
you
> help?
> 
> 
> >
> >>
> >> ...and in an email thread with Jochen.
> >>
> >> https://codereview.chromium.org/2311723002/
> >>
> >
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Chromium-reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

My understanding is that part of the reason for moving out of //components is it
won't be used on ios... one of the bugs linked in https://crbug.com/624590
indicates a desire to simplify the rules for what go in //components to make it
easier to understand what should go actually there. Usually, this means it'd
live in //content, but //net doesn't want to depend on //content at all.

That being said, it does feel a bit weird for this to live in //base: it's just
a thin wrapper around an ObserverList.

Out of curiosity... is this something that would make sense in //services?
There's already a mojo component AFAIK, but I'm not quite sure what makes
something a service.

[bashi, 2016-09-12 23:00:26]

bashi@chromium.org changed reviewers:
+ jochen@chromium.org

[bashi, 2016-09-12 23:16:29]

+jochen@

It seems that we don't reach a consensus about where to put memory coordinator.
I don't have a strong opinion about the code location but I do want to keep
implementing memory coordinator (e.g. landing
https://codereview.chromium.org/2259743002/ without code location discussion).
How about putting it in components/ for now?

On 2016/09/09 18:45:53, dcheng wrote:
> On 2016/09/09 18:38:56, danakj wrote:
> > On Fri, Sep 9, 2016 at 11:32 AM, <mailto:danakj@chromium.org> wrote:
> > 
> > > On Fri, Sep 9, 2016 at 8:13 AM, <mailto:chrisha@chromium.org> wrote:
> > >
> > >> On 2016/09/09 14:50:38, Nico wrote:
> > >> > danakj has been doing a lot of discussions about what stuff should go
> > >> where.
> > >> In
> > >> > the past, I think the guideline was "if in doubt, components/", but the
> > >> linked
> > >> > bug suggests that that's no longer true. I don't want some ~random
> > >> subset of
> > >> > stuff moving into base, so I'm hoping there's some plan to prevent that
> > >> --
> > >> > danakj, do you know the story here?
> > >> >
> > >> > (Maybe dcheng knows too; I don't.)
> > >>
> > >> We originally planned on being a component, but ran into a few
roadblocks.
> > >> Namely, we have clients in 'net', and they can't depend on components but
> > >> can
> > >> depend on base.
> > >>
> > >
> > > Every component is individual, so it can depend on your component without
> > > depending on the rest, no?
> > >
> > 
> > 
> > >
> > >
> > >> We've tried to make as narrow as possible the part of the system
> > >> that lives in base (basically an interface definition and a client
> > >> registry),
> > >> with the vast majority of logic living in content.
> > >>
> > >> The linked bug and doc doesn't contain the full backstory. More details
> > >> available here:
> > >>
> > >> https://codereview.chromium.org/2259743002/
> > >>
> > >
> > The only context I can really see in there is that people wanted content/
> > but that won't make sense cuz net/ uses it, but then jochen says:
> > 
> > "offline discussion revealed that net/ is supposed to depend on this, so we
> > can't move the code either to content/ nor components/, but need to find a
> > new place. I suggested base/"
> > 
> > But I as above, I don't get why net/ can't depend on a single component. It
> > doesn't have to depend on them all. mailto:[+agl@chromium.org] from net/ can
> you
> > help?
> > 
> > 
> > >
> > >>
> > >> ...and in an email thread with Jochen.
> > >>
> > >> https://codereview.chromium.org/2311723002/
> > >>
> > >
> > >
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups
> > "Chromium-reviews" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email
> > to mailto:chromium-reviews+unsubscribe@chromium.org.
> 
> My understanding is that part of the reason for moving out of //components is
it
> won't be used on ios... one of the bugs linked in https://crbug.com/624590
> indicates a desire to simplify the rules for what go in //components to make
it
> easier to understand what should go actually there. Usually, this means it'd
> live in //content, but //net doesn't want to depend on //content at all.
> 
> That being said, it does feel a bit weird for this to live in //base: it's
just
> a thin wrapper around an ObserverList.
> 
> Out of curiosity... is this something that would make sense in //services?
> There's already a mojo component AFAIK, but I'm not quite sure what makes
> something a service.

Hmm, I'm not sure what //services are.

[haraken, 2016-09-13 05:07:40]

Just a drive-by, but this is blocking a bunch of CLs for landing
MemoryCoordinator & purge + suspend. So I might want to separate the
architectural discussion from landing the feature.

[haraken, 2016-09-14 02:02:32]

On 2016/09/13 05:07:40, haraken wrote:
> Just a drive-by, but this is blocking a bunch of CLs for landing
> MemoryCoordinator & purge + suspend. So I might want to separate the
> architectural discussion from landing the feature.

Any further comment about how to proceed with this CL? Or does PS3 look good
until we figure out how MemoryCoordinator should fit in the servicification
project?

I'd like to land this CL asap since it's blocking a bunch of CLs for
MemoryCoordinator.

[danakj, 2016-09-14 02:33:51]

On Tue, Sep 13, 2016 at 7:02 PM, <haraken@chromium.org> wrote:

> On 2016/09/13 05:07:40, haraken wrote:
> > Just a drive-by, but this is blocking a bunch of CLs for landing
> > MemoryCoordinator & purge + suspend. So I might want to separate the
> > architectural discussion from landing the feature.
>
> Any further comment about how to proceed with this CL? Or does PS3 look
> good
> until we figure out how MemoryCoordinator should fit in the servicification
> project?
>
> I'd like to land this CL asap since it's blocking a bunch of CLs for
> MemoryCoordinator.
>

Landing stuff in base/ to unblock things without sorting it out seems
wrong, there's super no undo button there.

Maybe jochen can comment but I think it should go in components/ for now
especially if we're looking for a temporary solution.


>
>
> https://codereview.chromium.org/2311723002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[jochen (gone - plz use gerrit), 2016-09-14 09:02:35]

components/ isn't a temporary dumping ground either....

Maybe we should have a VC or something to figure out the architecture? If it
helps with timezones, jam@ can probably represent what should go into
components/ and what shouldn't

[haraken, 2016-09-14 12:33:07]

On 2016/09/14 09:02:35, jochen wrote:
> components/ isn't a temporary dumping ground either....
> 
> Maybe we should have a VC or something to figure out the architecture? If it
> helps with timezones, jam@ can probably represent what should go into
> components/ and what shouldn't

We need to choose either of MTV+TOK or MTV+EMEA, but do you mind if we do
MTV+TOK first?

[haraken, 2016-09-14 12:34:17]

haraken@chromium.org changed reviewers:
+ jam@chromium.org

[haraken, 2016-09-14 12:34:18]

+jam: FYI. We're discussing where MemoryCoordinator should be added.

[jam, 2016-09-14 17:15:42]

Dana: base/memory/memory_coordinator_client* replaces
base/memory/memory_pressure*, so this seems natural to go into base.

Having net/ depend on even a new component is both confusing to developers to
understand the layer cake, and also not trivial since net/ is shipped to other
consumers. Historically when we hit this situation we moved code to base/. I
understand the need to keep base minimal, but we should also balance that with
making our layer tree cake understandable.

Happy to VC.

[jam, 2016-09-14 17:16:33]

fwiw this lgtm

[danakj, 2016-09-14 17:23:32]

On Wed, Sep 14, 2016 at 10:15 AM, <jam@chromium.org> wrote:

> Dana: base/memory/memory_coordinator_client* replaces
> base/memory/memory_pressure*, so this seems natural to go into base.
>
> Having net/ depend on even a new component is both confusing to developers
> to
> understand the layer cake,
>

I agree with that, but also don't think this is a one-off example of this
and we need a general solution and that general solution won't be to put
everything in base, which is why I'm feeling cautious that we don't make
that the default solution for components.


> and also not trivial since net/ is shipped to other
> consumers. Historically when we hit this situation we moved code to base/.
>

Thanks jam, I hadn't heard/understood a reason for net to not depend on a
component, so this is really helpful. I was not aware we ship net/ to other
consumers similar to base.


> I understand the need to keep base minimal, but we should also balance
> that with
> making our layer tree cake understandable.
>
> Happy to VC.
>
> https://codereview.chromium.org/2311723002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[danakj, 2016-09-14 17:25:09]

base/ LGTM

[bashi, 2016-09-14 22:16:26]

Thank you!

If dcheng@ is OK with this, I'll land the CL.

[dcheng, 2016-09-15 00:18:44]

On 2016/09/14 22:16:26, bashi1 wrote:
> Thank you!
> 
> If dcheng@ is OK with this, I'll land the CL.

Yes, it looks like all the concerns have been resolved. LGTM

[dcheng, 2016-09-15 00:19:19]

https://codereview.chromium.org/2311723002/diff/40001/base/memory/memory_coor...
File base/memory/memory_coordinator_client.h (right):

https://codereview.chromium.org/2311723002/diff/40001/base/memory/memory_coor...
base/memory/memory_coordinator_client.h:12: // MemoryState represents status of
a process.
Btw, not sure if you want to update these comments or not (since I think they're
a bit different in the mojom)

[bashi, 2016-09-15 00:28:14]

https://codereview.chromium.org/2311723002/diff/40001/base/memory/memory_coor...
File base/memory/memory_coordinator_client.h (right):

https://codereview.chromium.org/2311723002/diff/40001/base/memory/memory_coor...
base/memory/memory_coordinator_client.h:12: // MemoryState represents status of
a process.
On 2016/09/15 00:19:19, dcheng wrote:
> Btw, not sure if you want to update these comments or not (since I think
they're
> a bit different in the mojom)

Yeah, I'll update the comments to refer .mojom

[bashi, 2016-09-15 00:39:40]

https://codereview.chromium.org/2311723002/diff/40001/base/memory/memory_coor...
File base/memory/memory_coordinator_client.h (right):

https://codereview.chromium.org/2311723002/diff/40001/base/memory/memory_coor...
base/memory/memory_coordinator_client.h:12: // MemoryState represents status of
a process.
On 2016/09/15 00:28:13, bashi1 wrote:
> On 2016/09/15 00:19:19, dcheng wrote:
> > Btw, not sure if you want to update these comments or not (since I think
> they're
> > a bit different in the mojom)
> 
> Yeah, I'll update the comments to refer .mojom

Moved comments from
components/memory_coordinator/public/interfaces/child_memory_coordinator.mojom
to here.

[bashi, 2016-09-15 00:39:51]

The CQ bit was checked by bashi@chromium.org

[bashi, 2016-09-15 00:39:52]

The patchset sent to the CQ was uploaded after l-g-t-m from
haraken@chromium.org, chrisha@chromium.org, tasak@google.com, sky@chromium.org,
jam@chromium.org, dcheng@chromium.org, danakj@chromium.org
Link to the patchset: https://codereview.chromium.org/2311723002/#ps60001
(title: "Update comments")

[commit-bot: I haz the power, 2016-09-15 00:40:42]

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, 2016-09-15 02:44:49]

Description was changed from

==========
Move memory_coordinator_client and its registry to base/memory

This is the first CL to move memory_coordinator outside components/.
Also, per discussion on [1], this CL removes MemoryCoordinatorClient
from HistoryBackend. We can re-add it if needed.

[1] https://codereview.chromium.org/2297243004/#msg14

BUG=644022
==========

to

==========
Move memory_coordinator_client and its registry to base/memory

This is the first CL to move memory_coordinator outside components/.
Also, per discussion on [1], this CL removes MemoryCoordinatorClient
from HistoryBackend. We can re-add it if needed.

[1] https://codereview.chromium.org/2297243004/#msg14

BUG=644022
==========

[commit-bot: I haz the power, 2016-09-15 02:44:51]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-09-15 02:47:52]

Description was changed from

==========
Move memory_coordinator_client and its registry to base/memory

This is the first CL to move memory_coordinator outside components/.
Also, per discussion on [1], this CL removes MemoryCoordinatorClient
from HistoryBackend. We can re-add it if needed.

[1] https://codereview.chromium.org/2297243004/#msg14

BUG=644022
==========

to

==========
Move memory_coordinator_client and its registry to base/memory

This is the first CL to move memory_coordinator outside components/.
Also, per discussion on [1], this CL removes MemoryCoordinatorClient
from HistoryBackend. We can re-add it if needed.

[1] https://codereview.chromium.org/2297243004/#msg14

BUG=644022

Committed: https://crrev.com/e70150fb5845bf645adec87036eca3b789d7ddcc
Cr-Commit-Position: refs/heads/master@{#418766}
==========

[commit-bot: I haz the power, 2016-09-15 02:47:54]

Patchset 4 (id:??) landed as
https://crrev.com/e70150fb5845bf645adec87036eca3b789d7ddcc
Cr-Commit-Position: refs/heads/master@{#418766}