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

base/memory/discardable_memory_allocator_android.h

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef BASE_MEMORY_DISCARDABLE_MEMORY_ALLOCATOR_H_
 #define BASE_MEMORY_DISCARDABLE_MEMORY_ALLOCATOR_H_
 
 #include <string>
 
 #include "base/base_export.h"
@@ skipping 26 matching lines @@
   // ashmem regions and is expected to be greater or equal than 32 MBytes.
   DiscardableMemoryAllocator(const std::string& name,
                              size_t ashmem_region_size);
 
   ~DiscardableMemoryAllocator();
 
   // Note that the allocator must outlive the returned DiscardableMemory
   // 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;
 
   void DeleteAshmemRegion_Locked(AshmemRegion* region);
 
   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);
 };
 
 }  // namespace internal
 }  // namespace base
 
 #endif  // BASE_MEMORY_DISCARDABLE_MEMORY_ALLOCATOR_H_