Remove renderer notifications of memory pressure.

Remove renderer notifications of memory pressure.

This system sends messages to the renderer processes when the system is under memory
strain. But when the system is under memory strain, garbage collecting makes thrashing
worse. When we're under memory pressure, waking up the least-recently-used renderer
and making it touch a lot of its memory by GC-ing will likely page in that renderer.

The current system does this for all renderers repeatedly (one every two seconds, looping
back to the least-recently-used one again) until there is no more memory pressure. This
system contributes to the "falling off a cliff" behavior of Chrome performance when
under memory pressure.

Now that renderers are not notified of memory pressure, the messages associated with this,
as well as messages to simulate and disable notifications are removed.

With this change, the browser process will continue to respond to memory pressure events
and may clear some caches, but the renderers will not. They will presumably get paged
out like normal processes. This affects only desktop systems. A separate memory pressure
system exists on Android, and the messages were already disabled on ChromeOS due to the
problems they caused.

This mostly reverts these patches:
https://codereview.chromium.org/1332583002
https://codereview.chromium.org/1641813002

Changes TabStats to use C++11-style member initialization and implements move and
assignment operators out-of-line.

BUG=716606
R=erikchen@chromium.org
TBR=mbarbella@chromium.org (security IPC review for messages removal)

Review-Url: https://codereview.chromium.org/2882513004
Cr-Commit-Position: refs/heads/master@{#471942}
Committed: https://chromium.googlesource.com/chromium/src/+/37c4e81eb4dfa713a06164dbce721710b92b2ca9

[brettw, 2017-05-11 22:51:05]

Description was changed from

==========
Remove renderer notifications of memory pressure.

This system sends messages to the renderer processes when the system is under
memory
strain. But when the system is under memory strain, garbage collecting makes
thrashing
worse. When we're under memory pressure, waking up the least-recently-used
renderer
and making it touch a lot of its memory by GC-ing will likely page in that
renderer.

The current system does this for all renderers repeatedly (one every two
seconds, looping
back to the least-recently-used one again) until there is no more memory
pressure. This
system contributes to the "falling off a cliff" behavior of Chrome performance
when
under memory pressure.

Now that renderers are not notified of memory pressure, the messages associated
with this,
as well as messages to simulate and disable notifications are removed.

With this change, the browser process will continue to respond to memory
pressure events
and may clear some caches, but the renderers will not. They will presumably get
paged
out like normal processes. This affects only desktop systems. A separate memory
pressure
system exists on Android, and the messages were already disabled on ChromeOS due
to the
problems they caused.

This mostly reverts these patches:
https://codereview.chromium.org/1332583002
https://codereview.chromium.org/1641813002
==========

to

==========
Remove renderer notifications of memory pressure.

This system sends messages to the renderer processes when the system is under
memory
strain. But when the system is under memory strain, garbage collecting makes
thrashing
worse. When we're under memory pressure, waking up the least-recently-used
renderer
and making it touch a lot of its memory by GC-ing will likely page in that
renderer.

The current system does this for all renderers repeatedly (one every two
seconds, looping
back to the least-recently-used one again) until there is no more memory
pressure. This
system contributes to the "falling off a cliff" behavior of Chrome performance
when
under memory pressure.

Now that renderers are not notified of memory pressure, the messages associated
with this,
as well as messages to simulate and disable notifications are removed.

With this change, the browser process will continue to respond to memory
pressure events
and may clear some caches, but the renderers will not. They will presumably get
paged
out like normal processes. This affects only desktop systems. A separate memory
pressure
system exists on Android, and the messages were already disabled on ChromeOS due
to the
problems they caused.

This mostly reverts these patches:
https://codereview.chromium.org/1332583002
https://codereview.chromium.org/1641813002

BUG=716606
==========

[brettw, 2017-05-11 22:51:15]

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

[commit-bot: I haz the power, 2017-05-11 22:52:31]

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 22:59:03]

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

[commit-bot: I haz the power, 2017-05-11 22:59:05]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[brettw, 2017-05-12 18:01:54]

Merge

[brettw, 2017-05-12 18:01:55]

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

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

Dry run: CQ is trying da patch.

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

[brettw, 2017-05-12 19:16:16]

Description was changed from

==========
Remove renderer notifications of memory pressure.

This system sends messages to the renderer processes when the system is under
memory
strain. But when the system is under memory strain, garbage collecting makes
thrashing
worse. When we're under memory pressure, waking up the least-recently-used
renderer
and making it touch a lot of its memory by GC-ing will likely page in that
renderer.

The current system does this for all renderers repeatedly (one every two
seconds, looping
back to the least-recently-used one again) until there is no more memory
pressure. This
system contributes to the "falling off a cliff" behavior of Chrome performance
when
under memory pressure.

Now that renderers are not notified of memory pressure, the messages associated
with this,
as well as messages to simulate and disable notifications are removed.

With this change, the browser process will continue to respond to memory
pressure events
and may clear some caches, but the renderers will not. They will presumably get
paged
out like normal processes. This affects only desktop systems. A separate memory
pressure
system exists on Android, and the messages were already disabled on ChromeOS due
to the
problems they caused.

This mostly reverts these patches:
https://codereview.chromium.org/1332583002
https://codereview.chromium.org/1641813002

BUG=716606
==========

to

==========
Remove renderer notifications of memory pressure.

This system sends messages to the renderer processes when the system is under
memory
strain. But when the system is under memory strain, garbage collecting makes
thrashing
worse. When we're under memory pressure, waking up the least-recently-used
renderer
and making it touch a lot of its memory by GC-ing will likely page in that
renderer.

The current system does this for all renderers repeatedly (one every two
seconds, looping
back to the least-recently-used one again) until there is no more memory
pressure. This
system contributes to the "falling off a cliff" behavior of Chrome performance
when
under memory pressure.

Now that renderers are not notified of memory pressure, the messages associated
with this,
as well as messages to simulate and disable notifications are removed.

With this change, the browser process will continue to respond to memory
pressure events
and may clear some caches, but the renderers will not. They will presumably get
paged
out like normal processes. This affects only desktop systems. A separate memory
pressure
system exists on Android, and the messages were already disabled on ChromeOS due
to the
problems they caused.

This mostly reverts these patches:
https://codereview.chromium.org/1332583002
https://codereview.chromium.org/1641813002

Changes TabStats to use C++11-style member initialization and implements move
and
assignment operators out-of-line.

BUG=716606
==========

[brettw, 2017-05-12 19:16:16]

brettw@chromium.org changed reviewers:
+ erikchen@chromium.org

[erikchen, 2017-05-12 19:55:31]

erikchen@chromium.org changed reviewers:
+ chrisha@chromium.org

[erikchen, 2017-05-12 19:55:32]

lgtm with some questions:

[partly directed at chrisha@, partly at brettw@]

Is this the type of change that is so obviously correct that we should make it
without a Finch experiment or [un]launch review?

Presumably there are/were metrics that measured the impact of this code? Was it
significant? Do we expect regressions? Should we expect performance
improvements?

If this change does cause regressions, who is going to notice?

Maybe the answer to all of these questions is that the original feature had no
metrics, and therefore couldn't be verified to be positive or negative, and that
we are likewise not going to measure the removal of this feature.

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

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

[commit-bot: I haz the power, 2017-05-12 20:02:06]

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

[brettw, 2017-05-12 20:05:58]

On 2017/05/12 19:55:32, erikchen wrote:
> lgtm with some questions:
> 
> [partly directed at chrisha@, partly at brettw@]
> 
> Is this the type of change that is so obviously correct that we should make it
> without a Finch experiment or [un]launch review?
> 
> Presumably there are/were metrics that measured the impact of this code? Was
it
> significant? Do we expect regressions? Should we expect performance
> improvements?
> 
> If this change does cause regressions, who is going to notice?
> 
> Maybe the answer to all of these questions is that the original feature had no
> metrics, and therefore couldn't be verified to be positive or negative, and
that
> we are likewise not going to measure the removal of this feature.

I spent the first part of the week writing some metrics and experiments for
this, for example:
  https://codereview.chromium.org/2872743002
  https://codereview.chromium.org/2876793005
But after I realized that it repeatedly sends notifications while there is
pressure, that notifications are broken on Mac in some cases (now fixed), and
that it's completely disabled on ChromeOS due to problems it was causing, I
concluded that the current state is just broken and it will be better to start
with a clean slate with the memory coordinator.

[brettw, 2017-05-12 20:06:40]

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

[commit-bot: I haz the power, 2017-05-12 20:07:17]

Dry run: CQ is trying da patch.

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

[erikchen, 2017-05-12 20:07:55]

On 2017/05/12 20:05:58, brettw wrote:
> On 2017/05/12 19:55:32, erikchen wrote:
> > lgtm with some questions:
> > 
> > [partly directed at chrisha@, partly at brettw@]
> > 
> > Is this the type of change that is so obviously correct that we should make
it
> > without a Finch experiment or [un]launch review?
> > 
> > Presumably there are/were metrics that measured the impact of this code? Was
> it
> > significant? Do we expect regressions? Should we expect performance
> > improvements?
> > 
> > If this change does cause regressions, who is going to notice?
> > 
> > Maybe the answer to all of these questions is that the original feature had
no
> > metrics, and therefore couldn't be verified to be positive or negative, and
> that
> > we are likewise not going to measure the removal of this feature.
> 
> I spent the first part of the week writing some metrics and experiments for
> this, for example:
>   https://codereview.chromium.org/2872743002
>   https://codereview.chromium.org/2876793005
> But after I realized that it repeatedly sends notifications while there is
> pressure, that notifications are broken on Mac in some cases (now fixed), and
> that it's completely disabled on ChromeOS due to problems it was causing, I
> concluded that the current state is just broken and it will be better to start
> with a clean slate with the memory coordinator.

acknowledged. still lgtm

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

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

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

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

[brettw, 2017-05-15 16:56:29]

The CQ bit was checked by brettw@chromium.org

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

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 17:12:38]

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

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

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[brettw, 2017-05-15 20:20:31]

Description was changed from

==========
Remove renderer notifications of memory pressure.

This system sends messages to the renderer processes when the system is under
memory
strain. But when the system is under memory strain, garbage collecting makes
thrashing
worse. When we're under memory pressure, waking up the least-recently-used
renderer
and making it touch a lot of its memory by GC-ing will likely page in that
renderer.

The current system does this for all renderers repeatedly (one every two
seconds, looping
back to the least-recently-used one again) until there is no more memory
pressure. This
system contributes to the "falling off a cliff" behavior of Chrome performance
when
under memory pressure.

Now that renderers are not notified of memory pressure, the messages associated
with this,
as well as messages to simulate and disable notifications are removed.

With this change, the browser process will continue to respond to memory
pressure events
and may clear some caches, but the renderers will not. They will presumably get
paged
out like normal processes. This affects only desktop systems. A separate memory
pressure
system exists on Android, and the messages were already disabled on ChromeOS due
to the
problems they caused.

This mostly reverts these patches:
https://codereview.chromium.org/1332583002
https://codereview.chromium.org/1641813002

Changes TabStats to use C++11-style member initialization and implements move
and
assignment operators out-of-line.

BUG=716606
==========

to

==========
Remove renderer notifications of memory pressure.

This system sends messages to the renderer processes when the system is under
memory
strain. But when the system is under memory strain, garbage collecting makes
thrashing
worse. When we're under memory pressure, waking up the least-recently-used
renderer
and making it touch a lot of its memory by GC-ing will likely page in that
renderer.

The current system does this for all renderers repeatedly (one every two
seconds, looping
back to the least-recently-used one again) until there is no more memory
pressure. This
system contributes to the "falling off a cliff" behavior of Chrome performance
when
under memory pressure.

Now that renderers are not notified of memory pressure, the messages associated
with this,
as well as messages to simulate and disable notifications are removed.

With this change, the browser process will continue to respond to memory
pressure events
and may clear some caches, but the renderers will not. They will presumably get
paged
out like normal processes. This affects only desktop systems. A separate memory
pressure
system exists on Android, and the messages were already disabled on ChromeOS due
to the
problems they caused.

This mostly reverts these patches:
https://codereview.chromium.org/1332583002
https://codereview.chromium.org/1641813002

Changes TabStats to use C++11-style member initialization and implements move
and
assignment operators out-of-line.

BUG=716606
R=erikchen@chromium.org
TBR=meacer@chromium.org (security IPC review for messages removal)
==========

[brettw, 2017-05-15 20:21:22]

Description was changed from

==========
Remove renderer notifications of memory pressure.

This system sends messages to the renderer processes when the system is under
memory
strain. But when the system is under memory strain, garbage collecting makes
thrashing
worse. When we're under memory pressure, waking up the least-recently-used
renderer
and making it touch a lot of its memory by GC-ing will likely page in that
renderer.

The current system does this for all renderers repeatedly (one every two
seconds, looping
back to the least-recently-used one again) until there is no more memory
pressure. This
system contributes to the "falling off a cliff" behavior of Chrome performance
when
under memory pressure.

Now that renderers are not notified of memory pressure, the messages associated
with this,
as well as messages to simulate and disable notifications are removed.

With this change, the browser process will continue to respond to memory
pressure events
and may clear some caches, but the renderers will not. They will presumably get
paged
out like normal processes. This affects only desktop systems. A separate memory
pressure
system exists on Android, and the messages were already disabled on ChromeOS due
to the
problems they caused.

This mostly reverts these patches:
https://codereview.chromium.org/1332583002
https://codereview.chromium.org/1641813002

Changes TabStats to use C++11-style member initialization and implements move
and
assignment operators out-of-line.

BUG=716606
R=erikchen@chromium.org
TBR=meacer@chromium.org (security IPC review for messages removal)
==========

to

==========
Remove renderer notifications of memory pressure.

This system sends messages to the renderer processes when the system is under
memory
strain. But when the system is under memory strain, garbage collecting makes
thrashing
worse. When we're under memory pressure, waking up the least-recently-used
renderer
and making it touch a lot of its memory by GC-ing will likely page in that
renderer.

The current system does this for all renderers repeatedly (one every two
seconds, looping
back to the least-recently-used one again) until there is no more memory
pressure. This
system contributes to the "falling off a cliff" behavior of Chrome performance
when
under memory pressure.

Now that renderers are not notified of memory pressure, the messages associated
with this,
as well as messages to simulate and disable notifications are removed.

With this change, the browser process will continue to respond to memory
pressure events
and may clear some caches, but the renderers will not. They will presumably get
paged
out like normal processes. This affects only desktop systems. A separate memory
pressure
system exists on Android, and the messages were already disabled on ChromeOS due
to the
problems they caused.

This mostly reverts these patches:
https://codereview.chromium.org/1332583002
https://codereview.chromium.org/1641813002

Changes TabStats to use C++11-style member initialization and implements move
and
assignment operators out-of-line.

BUG=716606
R=erikchen@chromium.org
TBR=mbarbella@chromium.org (security IPC review for messages removal)
==========

[brettw, 2017-05-15 20:21:22]

brettw@chromium.org changed reviewers:
+ mbarbella@chromium.org

[brettw, 2017-05-15 20:21:50]

TBR mbarbella@chromium.org for IPC messages security review (this patch just
removes some).

[brettw, 2017-05-15 20:22:37]

The CQ bit was checked by brettw@chromium.org

[commit-bot: I haz the power, 2017-05-15 20:23:36]

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 22:07:59]

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

[commit-bot: I haz the power, 2017-05-15 22:08:00]

Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[brettw, 2017-05-15 22:29:06]

The CQ bit was checked by brettw@chromium.org

[commit-bot: I haz the power, 2017-05-15 22:30:04]

CQ is trying da patch.

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

[Martin Barbella, 2017-05-15 22:50:14]

ipc changes lgtm

[commit-bot: I haz the power, 2017-05-15 23:20:19]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1494887346486530,
"parent_rev": "25ac3c481a621cec69d1dec92abb7efee9a33d27", "commit_rev":
"37c4e81eb4dfa713a06164dbce721710b92b2ca9"}

[commit-bot: I haz the power, 2017-05-15 23:20:31]

Description was changed from

==========
Remove renderer notifications of memory pressure.

This system sends messages to the renderer processes when the system is under
memory
strain. But when the system is under memory strain, garbage collecting makes
thrashing
worse. When we're under memory pressure, waking up the least-recently-used
renderer
and making it touch a lot of its memory by GC-ing will likely page in that
renderer.

The current system does this for all renderers repeatedly (one every two
seconds, looping
back to the least-recently-used one again) until there is no more memory
pressure. This
system contributes to the "falling off a cliff" behavior of Chrome performance
when
under memory pressure.

Now that renderers are not notified of memory pressure, the messages associated
with this,
as well as messages to simulate and disable notifications are removed.

With this change, the browser process will continue to respond to memory
pressure events
and may clear some caches, but the renderers will not. They will presumably get
paged
out like normal processes. This affects only desktop systems. A separate memory
pressure
system exists on Android, and the messages were already disabled on ChromeOS due
to the
problems they caused.

This mostly reverts these patches:
https://codereview.chromium.org/1332583002
https://codereview.chromium.org/1641813002

Changes TabStats to use C++11-style member initialization and implements move
and
assignment operators out-of-line.

BUG=716606
R=erikchen@chromium.org
TBR=mbarbella@chromium.org (security IPC review for messages removal)
==========

to

==========
Remove renderer notifications of memory pressure.

This system sends messages to the renderer processes when the system is under
memory
strain. But when the system is under memory strain, garbage collecting makes
thrashing
worse. When we're under memory pressure, waking up the least-recently-used
renderer
and making it touch a lot of its memory by GC-ing will likely page in that
renderer.

The current system does this for all renderers repeatedly (one every two
seconds, looping
back to the least-recently-used one again) until there is no more memory
pressure. This
system contributes to the "falling off a cliff" behavior of Chrome performance
when
under memory pressure.

Now that renderers are not notified of memory pressure, the messages associated
with this,
as well as messages to simulate and disable notifications are removed.

With this change, the browser process will continue to respond to memory
pressure events
and may clear some caches, but the renderers will not. They will presumably get
paged
out like normal processes. This affects only desktop systems. A separate memory
pressure
system exists on Android, and the messages were already disabled on ChromeOS due
to the
problems they caused.

This mostly reverts these patches:
https://codereview.chromium.org/1332583002
https://codereview.chromium.org/1641813002

Changes TabStats to use C++11-style member initialization and implements move
and
assignment operators out-of-line.

BUG=716606
R=erikchen@chromium.org
TBR=mbarbella@chromium.org (security IPC review for messages removal)

Review-Url: https://codereview.chromium.org/2882513004
Cr-Commit-Position: refs/heads/master@{#471942}
Committed:
https://chromium.googlesource.com/chromium/src/+/37c4e81eb4dfa713a06164dbce72...
==========

[commit-bot: I haz the power, 2017-05-15 23:20:34]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/37c4e81eb4dfa713a06164dbce72...