Bug 1440824 - Enable multiple hashtables for atoms. r=froydnj
authorBobby Holley <bobbyholley@gmail.com>
Thu, 22 Feb 2018 15:59:00 -0800
changeset 405460 ef3ac3531192f937ba2e4758bf137503f0c5d916
parent 405459 5d83e440bbb0d9c9039db6d19cced9c8952d8501
child 405461 9438d4a380a25ec76ec6e465e06a6952fdcdb38c
push id60241
push userbholley@mozilla.com
push dateTue, 27 Feb 2018 02:45:01 +0000
treeherderautoland@ef3ac3531192 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersfroydnj
bugs1440824
milestone60.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1440824 - Enable multiple hashtables for atoms. r=froydnj MozReview-Commit-ID: Hj8gKPap0cR
xpcom/ds/nsAtomTable.cpp
--- a/xpcom/ds/nsAtomTable.cpp
+++ b/xpcom/ds/nsAtomTable.cpp
@@ -262,18 +262,44 @@ public:
   // on atoms concurrently. It's also slow, since it triggers a GC before
   // counting.
   size_t RacySlowCount();
 
   // This hash table op is a static member of this class so that it can take
   // advantage of |friend| declarations.
   static void AtomTableClearEntry(PLDHashTable* aTable, PLDHashEntryHdr* aEntry);
 
-  // XXXbholley: We enable multiple subtables in the next patch.
-  const static size_t kNumSubTables = 1; // Must be power of two.
+  // We achieve measurable reduction in locking contention in parallel CSS
+  // parsing by increasing the number of subtables up to 128. This has been
+  // measured to have neglible impact on the performance of initialization, GC,
+  // and shutdown.
+  //
+  // Another important consideration is memory, since we're adding fixed overhead
+  // per content process, which we try to avoid. Measuring a mostly-empty page [1]
+  // with various numbers of subtables, we get the following deep sizes for the
+  // atom table:
+  //       1 subtable:  278K
+  //       8 subtables: 279K
+  //      16 subtables: 282K
+  //      64 subtables: 286K
+  //     128 subtables: 290K
+  //
+  // So 128 subtables costs us 12K relative to a single table, and 4K relative
+  // to 64 subtables. Conversely, measuring parallel (6 thread) CSS parsing on
+  // tp6-facebook, a single table provides ~150ms of locking overhead per thread,
+  // 64 subtables provides ~2-3ms of overhead, and 128 subtables provides <1ms.
+  // And so while either 64 or 128 subtables would probably be acceptable,
+  // achieving a measurable reduction in contention for 4k of fixed memory
+  // overhead is probably worth it.
+  //
+  // [1] The numbers will look different for content processes with complex
+  // pages loaded, but in those cases the actual atoms will dominate memory
+  // usage and the overhead of extra tables will be negligible. We're mostly
+  // interested in the fixed cost for nearly-empty content processes.
+  const static size_t kNumSubTables = 128; // Must be power of two.
 
 private:
   nsAtomSubTable mSubTables[kNumSubTables];
 };
 
 // Static singleton instance for the atom table.
 static nsAtomTable* gAtomTable;