Align ashmem region sizes to page size after ashmem creation failed.

base/memory/discardable_memory_allocator_android.h

Index: base/memory/discardable_memory_allocator_android.h
diff --git a/base/memory/discardable_memory_allocator_android.h b/base/memory/discardable_memory_allocator_android.h
index 7ced405601ddea36d1800945174c929cd0475438..e99eb968d45ce6b406acc7fb8f99b14b91470595 100644
--- a/base/memory/discardable_memory_allocator_android.h
+++ b/base/memory/discardable_memory_allocator_android.h
@@ -44,6 +44,9 @@ class BASE_EXPORT_PRIVATE DiscardableMemoryAllocator {
   // instance.
   scoped_ptr<DiscardableMemory> Allocate(size_t size);
 
+  // Returns the size that is used to create ashmem regions.
+  size_t ashmem_region_size();

[willchan no longer on Chromium, 2014/01/15 00:37:49]

Should be const, and then you'd need to made the Lock mutable.

[Philippe, 2014/01/15 09:18:12]

Yeah, I thought it would have been slightly unfortunate to make the lock mutable
only for this testing method which doesn't need to be const in practice
(although having a getter like this not const looks really weird). But I'm also
fine with the 'mutable' :)

Completely off topic but I think we might need to reconsider your delegate idea
at some point to improve testability. It's still ok for now but at some point I
would like to consider adding some form of garbage collection of the unpinned
subranges which will depend on an ioctl() implemented by ashmem telling us
whether a subrange got evicted. We would need to mock that out for testing since
we would have no way otherwise to control the eviction of subranges.

The problem I would like to address with this is the fact that currently we can
end up with a few regions whose pages got completely evicted. Unfortunately we
have no way currently to reuse that space if the client keeps his (evicted)
DiscardableMemory instances alive. And he will keep them alive since image
decoding is moving to an "infinite" cache. This can lead to "bloating" the
address space since we are keeping the regions mapped (even though they have 0
private dirty bytes) which can in turn make large mmaps (e.g. by v8) fail. 
In fact the bug specified in the description is about that (although the problem
already existed with ashmem before we use the allocator). The website specified
in the bug looks like a pathological case though.

[willchan no longer on Chromium, 2014/01/16 01:52:37]

If there is any context on this "infinite" case thing, I'd love to read.
Bugs/docs? 

[Philippe, 2014/01/16 09:24:21]

I'm not aware of bugs/docs for this new infinite cache but hclam@ is. I've just
created this bug and hclam@ is also CC'ed on it :)
https://code.google.com/p/chromium/issues/detail?id=334996

+
  private:
   class AshmemRegion;
   class DiscardableAshmemChunk;
@@ -52,8 +55,8 @@ class BASE_EXPORT_PRIVATE DiscardableMemoryAllocator {
 
   base::ThreadChecker thread_checker_;
   const std::string name_;
-  const size_t ashmem_region_size_;
   base::Lock lock_;

[willchan no longer on Chromium, 2014/01/15 00:37:49]

Shouldn't need base:: here.

[Philippe, 2014/01/15 09:18:12]

Done.

+  size_t ashmem_region_size_;
   ScopedVector<AshmemRegion> ashmem_regions_;
 
   DISALLOW_COPY_AND_ASSIGN(DiscardableMemoryAllocator);