Add a field trial for using lower sqlite cache sizes.

chrome/browser/history/history_database.cc

Index: chrome/browser/history/history_database.cc
===================================================================
--- chrome/browser/history/history_database.cc	(revision 106923)
+++ chrome/browser/history/history_database.cc	(working copy)
@@ -14,6 +14,7 @@
 #include "base/rand_util.h"
 #include "base/string_util.h"
 #include "chrome/browser/diagnostics/sqlite_diagnostics.h"
+#include "chrome/browser/history/history_field_trial.h"
 #include "sql/transaction.h"
 
 #if defined(OS_MACOSX)
@@ -78,11 +79,15 @@
   // this is a NOP. Must be a power of 2 and a max of 8192.
   db_.set_page_size(4096);
 
-  // Increase the cache size. The page size, plus a little extra, times this
-  // value, tells us how much memory the cache will use maximum.
-  // 6000 * 4MB = 24MB
-  // TODO(brettw) scale this value to the amount of available memory.
-  db_.set_cache_size(6000);
+  if (HistoryFieldTrial::IsLowMemFieldTrial()) {
+    db_.set_cache_size(64);
+  } else {
+    // Increase the cache size. The page size, plus a little extra, times this
+    // value, tells us how much memory the cache will use maximum.
+    // 6000 * 4MB = 24MB
+    // TODO(brettw) scale this value to the amount of available memory.
+    db_.set_cache_size(6000);
+  }

[Scott Hess - ex-Googler, 2011/10/24 19:15:27]

Yeah, I'm with jar, this range is pretty huge.  I suspect that 6000 was not
providing much utility (most likely a small part of it was interior nodes, with
a ton of randomly-selected other pages), but since pages are atomic, when you
start to get so small as 64 you might start to see problems with thrashing.  It
might make sense to first prove a case for going below 500 (already saving 20M),
and worry about going further at that point if benefits haven't been capped.

 
   // Note that we don't set exclusive locking here. That's done by
   // BeginExclusiveMode below which is called later (we have to be in shared