Thanks for catching this. We should revert the purge + suspend asap.

(tasak@ will be back from vacation on next Monday.)

I would like to ask the reason why you looked at the changes.

I think, currently tab_manager.cc always notifies signals for purge+suspend (by the changes).
However, "begins suspending and purging tabs on the fly" is not correct.
Because in render_thread_impl.cc, purge+suspend checks whether kPurgeAnsSuspend is enabled or not. If not enabled, neither SuspendRenderer() nor Notify(SUSPENDED) are invoked.

> I have confirmed this in Chromium after adding some logging and changing the default time_to_first_suspension_sec to a smaller value like 60s.

Yes. I also need logging for control (for A/B testing). However, it doesn't mean Purge+Suspend is enabled.

> I would like to ask the reason why you looked at the changes.

I was looking for the cause of problem where Chrome is causing Macs to thrash on wake from sleep. It seemed like it might be due to an experiment, and I noticed PurgeAndSuspend.

> However, "begins suspending and purging tabs on the fly" is not correct

So you are saying that TabManager::PurgeAndSuspendBackgroundedTabs()'s call to tab.render_process_host->PurgeAndSuspend() ultimately calls RenderThreadImpl::SuspendRenderer(), and SuspendRenderer() is a no op if the feature is disabled?

>I was looking for the cause of problem where Chrome is causing Macs to thrash on wake from sleep. It seemed like it might be due to an experiment, and I noticed PurgeAndSuspend

Hmmm... I see. I'm not sure what causes the issue. Is it easy to reproduce the issue? I would like to check what happens.

> So you are saying that TabManager::PurgeAndSuspendBackgroundedTabs()'s call to tab.render_process_host->PurgeAndSuspend() ultimately calls RenderThreadImpl::SuspendRenderer(), and SuspendRenderer() is a no op if the feature is disabled?

To be more precise, RenderThreadImpl::OnProcessPurgeAndSuspend() and RenderThreadImpl::OnProcessResume() (which is invoked via tab.render_process_host->PurgeAndSuspend() and ->Resume()) are no op if the feature is disabled.

If the feature is disabled but the methods do someting, it's a purge+suspend bug. I have to fix.

> Hmmm... I see. I'm not sure what causes the issue. Is it easy to reproduce the issue? I would like to check what happens.

This is Issue 676082.

Thanks for the additional info - now that I understand better what your code is doing, it does look like it's working correctly.

If you launch Chrome and it restores 100 tabs, are those tabs fully loaded or are they essentially purged? I ask because if I launch Chrome and it fully restores 100 tabs, and most of those tabs sit idle, then it looks like PurgeAndSuspend could purge them all at once, which could really bog down your machine.

I also notice that the code does not check the machine's memory pressure state before purging a tab. On the Mac at least, doing a purge while the machine is in elevated memory pressure can make the situation worse. Maybe the loop in tab_manager should check memory pressure on each iteration and exit if it's higher than NORMAL?

Would you elaborate on why purging makes things worse when the machine is in elevated memory pressure on Mac?

For example, if a machine is swapping, freeing caches and other chunks of memory can cause that memory to be paged in from disk, further exacerbating the swapping.

I've written a doc about memory pressure on the Mac:

https://docs.google.com/a/google.com/document/d/10jRpINSqWgzUk1fITxm65w5tVUZ_YJc-W1onbz4jqME/edit?usp=sharing

Thanks for the write up! This is a great document :)

Glad it is helpful.