Oilpan: Add a RELEASE_ASSERT to catch out-of-virtual-address-space errors

Source/platform/heap/HeapPage.cpp

Index: Source/platform/heap/HeapPage.cpp
diff --git a/Source/platform/heap/HeapPage.cpp b/Source/platform/heap/HeapPage.cpp
index 24fb4dd15e91859d0e662b360b63ad7bee69e8c2..7733e6875fa651b1ef1e793a532c5a26cac8a169 100644
--- a/Source/platform/heap/HeapPage.cpp
+++ b/Source/platform/heap/HeapPage.cpp
@@ -522,6 +522,7 @@ void NormalPageHeap::allocatePage()
     threadState()->shouldFlushHeapDoesNotContainCache();
     PageMemory* pageMemory = Heap::freePagePool()->takeFreePage(heapIndex());
     // We continue allocating page memory until we succeed in committing one.
+    size_t numberOfTrials = 0;
     while (!pageMemory) {
         // Allocate a memory region for blinkPagesPerRegion pages that
         // will each have the following layout.
@@ -531,9 +532,8 @@ void NormalPageHeap::allocatePage()
         PageMemoryRegion* region = PageMemoryRegion::allocateNormalPages();
 
         // Setup the PageMemory object for each of the pages in the region.
-        size_t offset = 0;
         for (size_t i = 0; i < blinkPagesPerRegion; ++i) {
-            PageMemory* memory = PageMemory::setupPageMemoryInRegion(region, offset, blinkPagePayloadSize());
+            PageMemory* memory = PageMemory::setupPageMemoryInRegion(region, i * blinkPageSize, blinkPagePayloadSize());
             // Take the first possible page ensuring that this thread actually
             // gets a page and add the rest to the page pool.
             if (!pageMemory) {
@@ -544,8 +544,12 @@ void NormalPageHeap::allocatePage()
             } else {
                 Heap::freePagePool()->addFreePage(heapIndex(), memory);
             }
-            offset += blinkPageSize;
         }
+        ++numberOfTrials;
+        // If you hit the ASSERT, it means that you're hitting the limit of
+        // the number of mmapped regions OS can support
+        // (e.g., /proc/sys/vm/max_map_count in Linux).
+        RELEASE_ASSERT(numberOfTrials < 64);

[sof, 2015/09/08 05:30:34]

Could you explain a bit more what you were seeing? The PageMemoryRegion was able
to allocate (and not OOMedly crash), but something failed when setting up the
region?

[haraken, 2015/09/08 05:35:19]

The above memory->commit() starts failing (because mprotect fails) after we map
more than 65530 (/proc/sys/vm/max_map_count) regions.

[sof, 2015/09/08 06:25:57]

And once it does & that OS' limit is reached, the remaining blink pages will not
be committed.

I suppose a different way to handle it is to catch if all commit()s fail for a
region. But once we hit this resource exhausted state, a few more of these loop
iterations won't make much of a difference.

[haraken, 2015/09/08 06:33:14]

Right.

BTW, do you have any idea on why we have a 'while (!pageMemory)' loop? I guess
it's somehow related to threading race, but I don't understand why it's needed.

Also maybe can we just RELEASE_ASSERT once the first memory->commit() fails? I
don't think it fails (except for the out-of-virtual-memory scenario).

[sof, 2015/09/08 06:59:17]

Yes, it looks out of place to have a loop there now.

  http://codereview.chromium.org/393823003

added it for the purposes of repeatedly polling the cross-thread-usable free
page pool (after having filled it up with the pages of a new region.) As we now
take the first page & don't add that to the pool, the loop looks redundant.

     }
     NormalPage* page = new (pageMemory->writableStart()) NormalPage(pageMemory, this);
     page->link(&m_firstPage);