Move platform/MemoryPurgeController -> core/dom/MemoryCoordinator

Move platform/MemoryPurgeController -> core/dom/MemoryCoordinator

Reason for renaming:
We are going to replace MemoryPressureListener with memory coordinator[1].
The role of this class will not be limited to purge caches but also
handle other memory events like throttling.

Reason for moving platform to core:
MemoryCoordinator depends (and will depend) on things which live in core.
For example, it needs to ask MemoryCache to prune caches. It would also
ask StyleEngine to clear textToSheet and seetToText caches in the future.
Putting MemoryCoordinator in platform is a source of unwanted indirections.

Also, this CL removes MemoryPUrgeClient. It doesn't make sense to create an
instance of MemoryCoordinator per-page because the current implementation
doesn't do any per-page specific task. If we need to do a per-page specific
task in the future we can iterate over ordinaryPages() in MemoryCoordinator to
ask pages to execute the task.

BUG=617492
[1] https://docs.google.com/document/d/1dkUXXmpJk7xBUeQM-olBpTHJ2MXamDgY_kjNrl9JXMs

Committed: https://crrev.com/e9f7f82984084ef170e580cf6550154fbb585c6d
Cr-Commit-Position: refs/heads/master@{#400911}

[bashi, 2016-06-21 03:13:01]

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

[commit-bot: I haz the power, 2016-06-21 03:13:07]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2080813004/1

[bashi, 2016-06-21 03:48:13]

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

[bashi, 2016-06-21 03:48:13]

PTAL

[haraken, 2016-06-21 04:02:37]

Oilpan (in platform/) can be a client of the MemoryCoordinator. How will it
work? Are you planning to use a function pointer just like you're doing in
PartitionAlloc (in wtf/)?

[bashi, 2016-06-21 04:12:36]

On 2016/06/21 04:02:37, haraken wrote:
> Oilpan (in platform/) can be a client of the MemoryCoordinator. How will it
> work? Are you planning to use a function pointer just like you're doing in
> PartitionAlloc (in wtf/)?

For static methods and singleton methods like ThreadHeap::collectGarbage, we can
just call them from MemoryCoordinator (e.g.
WTF::Partitions::decommitFreeableMemory() in
MemoryCoordinator::onMemoryPressure).

If the above doesn't work we can re-add a client interface. I don't expect that
we need a client interface at this point.

[commit-bot: I haz the power, 2016-06-21 04:29:02]

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

[commit-bot: I haz the power, 2016-06-21 04:29:03]

Dry run: This issue passed the CQ dry run.

[haraken, 2016-06-21 05:13:11]

LGTM

How many files are you going to add to core/memory/? If the directory is going
to be very small, you could move the files to core/dom/. (I'm not sure if it's a
good idea but) currently we put these basic infrastructures in core/dom/. This
needs to be cleaned up in the Onion Soup.

[bashi, 2016-06-21 05:39:26]

On 2016/06/21 05:13:11, haraken wrote:
> LGTM
> 
> How many files are you going to add to core/memory/? If the directory is going
> to be very small, you could move the files to core/dom/. (I'm not sure if it's
a
> good idea but) currently we put these basic infrastructures in core/dom/. This
> needs to be cleaned up in the Onion Soup.

No files other than MemoryCoordinator.{cpp,h} are in my mind. Moved them to
core/dom.

[bashi, 2016-06-21 05:40:05]

The CQ bit was checked by bashi@chromium.org

[bashi, 2016-06-21 05:40:06]

The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org
Link to the patchset: https://codereview.chromium.org/2080813004/#ps20001
(title: "move to dom/")

[commit-bot: I haz the power, 2016-06-21 05:40:14]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2080813004/20001

[bashi, 2016-06-21 05:41:49]

The CQ bit was unchecked by bashi@chromium.org

[bashi, 2016-06-21 05:42:07]

Description was changed from

==========
Move platform/MemoryPurgeController -> core/memory/MemoryCoordinator

Reason for renaming:
We are going to replace MemoryPressureListener with memory coordinator[1].
The role of this class will not be limited to purge caches but also
handle other memory events like throttling.

Reason for moving platform to core:
MemoryCoordinator depends (and will depend) on things which live in core.
For example, it needs to ask MemoryCache to prune caches. It would also
ask StyleEngine to clear textToSheet and seetToText caches in the future.
Putting MemoryCoordinator in platform is a source of unwanted indirections.

Also, this CL removes MemoryPUrgeClient. It doesn't make sense to create an
instance of MemoryCoordinator per-page because the current implementation
doesn't do any per-page specific task. If we need to do a per-page specific
task in the future we can iterate over ordinaryPages() in MemoryCoordinator to
ask pages to execute the task.

BUG=617492

[1]
https://docs.google.com/document/d/1dkUXXmpJk7xBUeQM-olBpTHJ2MXamDgY_kjNrl9JXMs
==========

to

==========
Move platform/MemoryPurgeController -> core/dom/MemoryCoordinator

Reason for renaming:
We are going to replace MemoryPressureListener with memory coordinator[1].
The role of this class will not be limited to purge caches but also
handle other memory events like throttling.

Reason for moving platform to core:
MemoryCoordinator depends (and will depend) on things which live in core.
For example, it needs to ask MemoryCache to prune caches. It would also
ask StyleEngine to clear textToSheet and seetToText caches in the future.
Putting MemoryCoordinator in platform is a source of unwanted indirections.

Also, this CL removes MemoryPUrgeClient. It doesn't make sense to create an
instance of MemoryCoordinator per-page because the current implementation
doesn't do any per-page specific task. If we need to do a per-page specific
task in the future we can iterate over ordinaryPages() in MemoryCoordinator to
ask pages to execute the task.

BUG=617492

[1]
https://docs.google.com/document/d/1dkUXXmpJk7xBUeQM-olBpTHJ2MXamDgY_kjNrl9JXMs
==========

[bashi, 2016-06-21 05:42:16]

The CQ bit was checked by bashi@chromium.org

[commit-bot: I haz the power, 2016-06-21 05:42:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2080813004/20001

[commit-bot: I haz the power, 2016-06-21 06:57:31]

Description was changed from

==========
Move platform/MemoryPurgeController -> core/dom/MemoryCoordinator

Reason for renaming:
We are going to replace MemoryPressureListener with memory coordinator[1].
The role of this class will not be limited to purge caches but also
handle other memory events like throttling.

Reason for moving platform to core:
MemoryCoordinator depends (and will depend) on things which live in core.
For example, it needs to ask MemoryCache to prune caches. It would also
ask StyleEngine to clear textToSheet and seetToText caches in the future.
Putting MemoryCoordinator in platform is a source of unwanted indirections.

Also, this CL removes MemoryPUrgeClient. It doesn't make sense to create an
instance of MemoryCoordinator per-page because the current implementation
doesn't do any per-page specific task. If we need to do a per-page specific
task in the future we can iterate over ordinaryPages() in MemoryCoordinator to
ask pages to execute the task.

BUG=617492

[1]
https://docs.google.com/document/d/1dkUXXmpJk7xBUeQM-olBpTHJ2MXamDgY_kjNrl9JXMs
==========

to

==========
Move platform/MemoryPurgeController -> core/dom/MemoryCoordinator

Reason for renaming:
We are going to replace MemoryPressureListener with memory coordinator[1].
The role of this class will not be limited to purge caches but also
handle other memory events like throttling.

Reason for moving platform to core:
MemoryCoordinator depends (and will depend) on things which live in core.
For example, it needs to ask MemoryCache to prune caches. It would also
ask StyleEngine to clear textToSheet and seetToText caches in the future.
Putting MemoryCoordinator in platform is a source of unwanted indirections.

Also, this CL removes MemoryPUrgeClient. It doesn't make sense to create an
instance of MemoryCoordinator per-page because the current implementation
doesn't do any per-page specific task. If we need to do a per-page specific
task in the future we can iterate over ordinaryPages() in MemoryCoordinator to
ask pages to execute the task.

BUG=617492

[1]
https://docs.google.com/document/d/1dkUXXmpJk7xBUeQM-olBpTHJ2MXamDgY_kjNrl9JXMs
==========

[commit-bot: I haz the power, 2016-06-21 06:57:32]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-06-21 07:03:57]

Description was changed from

==========
Move platform/MemoryPurgeController -> core/dom/MemoryCoordinator

Reason for renaming:
We are going to replace MemoryPressureListener with memory coordinator[1].
The role of this class will not be limited to purge caches but also
handle other memory events like throttling.

Reason for moving platform to core:
MemoryCoordinator depends (and will depend) on things which live in core.
For example, it needs to ask MemoryCache to prune caches. It would also
ask StyleEngine to clear textToSheet and seetToText caches in the future.
Putting MemoryCoordinator in platform is a source of unwanted indirections.

Also, this CL removes MemoryPUrgeClient. It doesn't make sense to create an
instance of MemoryCoordinator per-page because the current implementation
doesn't do any per-page specific task. If we need to do a per-page specific
task in the future we can iterate over ordinaryPages() in MemoryCoordinator to
ask pages to execute the task.

BUG=617492

[1]
https://docs.google.com/document/d/1dkUXXmpJk7xBUeQM-olBpTHJ2MXamDgY_kjNrl9JXMs
==========

to

==========
Move platform/MemoryPurgeController -> core/dom/MemoryCoordinator

Reason for renaming:
We are going to replace MemoryPressureListener with memory coordinator[1].
The role of this class will not be limited to purge caches but also
handle other memory events like throttling.

Reason for moving platform to core:
MemoryCoordinator depends (and will depend) on things which live in core.
For example, it needs to ask MemoryCache to prune caches. It would also
ask StyleEngine to clear textToSheet and seetToText caches in the future.
Putting MemoryCoordinator in platform is a source of unwanted indirections.

Also, this CL removes MemoryPUrgeClient. It doesn't make sense to create an
instance of MemoryCoordinator per-page because the current implementation
doesn't do any per-page specific task. If we need to do a per-page specific
task in the future we can iterate over ordinaryPages() in MemoryCoordinator to
ask pages to execute the task.

BUG=617492

[1]
https://docs.google.com/document/d/1dkUXXmpJk7xBUeQM-olBpTHJ2MXamDgY_kjNrl9JXMs

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

[commit-bot: I haz the power, 2016-06-21 07:03:58]

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