There's a couple other similar reports:

https://feedback.corp.google.com/product/208/neutron?lView=rd&lReport=59487754391


"When switching between the same 2-3 tabs in one window, the tabs started re-loading on switch even though they were in "current" use.

Note: In general, this was not an issue earlier in the day when switching between current tabs."

and

https://feedback.corp.google.com/product/208/neutron?lView=rd&lReport=59565673792

"I think we're getting too many page reloads. I'm starting to see every page reload whenever I switch. @luigi, ben, sonny"

I don't think it's a LRU problem. It could be just all other tabs are already discarded so there's not choice but discarding the same tab again and again.

aaboagye@,
  You can go to about://discards to see the status of all tabs (whether they're discarded). 

On the other hand, we should probably 
1. Clean up log to make us better understand the situation
2. Protect an active tab for a while. For example, don't kill a tab if it's active in the past x minutes 

Regarding #3 point 2:

I don't think it's a good idea to stray away from LRU order.  However, the "U" part may be tricky.  What if someone clicks or control-tabs through several tabs to find or simply to select the desired one?  Exposing a tab briefly should not necessarily declare it "used".  Or should it?

I guess the first thing would be to gather (if needed) and examine UMA stats to see if this is a common enough occurrence.
 

https://chromium.googlesource.com/chromium/src/+/3f7781da5e43f9c32b5e4654e08b6d5386597fc9/chrome/browser/memory/tab_manager.cc#482 is the function for sorting tabs by its importance.

I'm not familiar with the code at all, but here is my impression:

(1) The function is not really (only) LRU. The function checks many things before checking |last_active|.

Let's say the user has the following tabs:

 Tab #1 (old): facebook with a pending form entry.
 Tab #2 (old): youtube, streaming audio
 Tab #3 (old): reddit, pinned
 Tab #4 (very new): gmail, selected

When tab #4 is selected, Chrome never kills it, but once the user switches to another tab, Chrome may immediately kill tab #4 because tabs with pending form, streaming audio, and pinned tabs are more important than #4 even though #4 is one of the most recently used tabs.

I'm not sure if this is really a problem, though. Maybe WAI.


(2) The function checks |last_active| but does not check the tab's creation time.

Looks like |last_active| (which I think is retrieved via content/public/browser/web_contents.h's GetLastActiveTime()) is updated immediately in Browser::ActiveTabChanged(). So if the user e.g. presses Ctrl+Tab ("next tab" shortcut) several times under memory pressure, I think the most recently created tab can easily be killed.

cylee's proposal 2. in comment#3 may fix this.


(3) The function does not seem to take renderer process sharing into account.

Let's say the user has 3 tabs:

 Tab #1 (very old): not important,            renderer PID=1234
 Tab #2 (new): important,                     renderer PID=2345
 Tab #3 (new): selected (the most important), renderer PID=1234

In this case, under low-mem condition, Chrome kills tab #1 first, but because of the renderer process sharing, that ends up killing tab #3 too which happens to be the most important.

I think we can avoid this type of issues by adding the following code to chrome/browser/memory/tab_manager_delegate_chromeos.cc:

 TabManagerDelegate::LowMemoryKillImpl() }
 [...]
 tabs = GetSortedCandidates(...)
 set<pid_t> seen;
 for (auto it = tabs.begin(); it != tabs.end(); ++it) {   // iterate from the most important to least important
   if (it->pid is in seen)
     remove it;    // this tab's renderer is also used by a more important tab. remove this from the kill-able tab list.
   else
     seen.insert(it->pid)
 }
 [...]

Thanks to yusukes for the explanation. But I think (3) doesn't work that way?
Although renderer process is shared, when discarding a tab it doesn't actually kill the process : https://cs.chromium.org/chromium/src/chrome/browser/memory/tab_manager.cc?rcl=5edc11d84b550e8b8eef08979a3cc7517000b939&l=375
If my understanding is correct, it only replaces the web content by a null content and only effect the specific tab.
(My logic in LowMemoryKillImpl() to estimate freed memory is misleading, apologize :) )

https://feedback.corp.google.com/#/Report/60773279621
looks like another report of the same (or similar) issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/576b449ac1a7a0fc6a3d55fec99bf5e6e91d4de2

commit 576b449ac1a7a0fc6a3d55fec99bf5e6e91d4de2
Author: cylee <cylee@chromium.org>
Date: Thu May 18 23:36:32 2017

TabManager: Add more logs to understand how it works when memory is low.

BUG= 721629 
TEST=tried on cave

Review-Url: https://codereview.chromium.org/2893943003
Cr-Commit-Position: refs/heads/master@{#472970}

[modify] https://crrev.com/576b449ac1a7a0fc6a3d55fec99bf5e6e91d4de2/chrome/browser/chromeos/arc/process/arc_process.cc
[modify] https://crrev.com/576b449ac1a7a0fc6a3d55fec99bf5e6e91d4de2/chrome/browser/chromeos/arc/process/arc_process.h
[modify] https://crrev.com/576b449ac1a7a0fc6a3d55fec99bf5e6e91d4de2/chrome/browser/memory/tab_manager_delegate_chromeos.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2969fddbb9bc81c4f449f19532557ee470197534

commit 2969fddbb9bc81c4f449f19532557ee470197534
Author: cylee <cylee@chromium.org>
Date: Wed May 24 08:09:35 2017

TabManager: Add more logs to understand how it works when memory is low.

BUG= 721629 
TEST=tried on cave
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2893943003
Cr-Original-Commit-Position: refs/heads/master@{#472970}
Review-Url: https://codereview.chromium.org/2896073002
Cr-Commit-Position: refs/branch-heads/3071@{#681}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/2969fddbb9bc81c4f449f19532557ee470197534/chrome/browser/chromeos/arc/process/arc_process.cc
[modify] https://crrev.com/2969fddbb9bc81c4f449f19532557ee470197534/chrome/browser/chromeos/arc/process/arc_process.h
[modify] https://crrev.com/2969fddbb9bc81c4f449f19532557ee470197534/chrome/browser/memory/tab_manager_delegate_chromeos.cc

I think logging is in now and we aren't trying to discard the same tab -- closing.