[Lldb-commits] [lldb] 0afdc7b - Revert "[lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates"

[Raphael Isemann via lldb-commits]

Author: Raphael Isemann
Date: 2020-02-03T11:09:45+01:00
New Revision: 0afdc7bed8adb9516dec8581af7f969b7d087946

URL: https://github.com/llvm/llvm-project/commit/0afdc7bed8adb9516dec8581af7f969b7d087946
DIFF: https://github.com/llvm/llvm-project/commit/0afdc7bed8adb9516dec8581af7f969b7d087946.diff

LOG: Revert "[lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates"

This reverts commit 500c324fa13eec2b171f4ea4dbed2ac1251f5aae because its parent commit
b848b510a8d52dbf50ee53a9a1ce844abb60d9bd is failing on the sanitizer bots.

Added: 
    

Modified: 
    lldb/source/Utility/ConstString.cpp

Removed: 
    


################################################################################
diff  --git a/lldb/source/Utility/ConstString.cpp b/lldb/source/Utility/ConstString.cpp
index fa40a2896b2a..4e353dfd44c2 100644
--- a/lldb/source/Utility/ConstString.cpp
+++ b/lldb/source/Utility/ConstString.cpp
@@ -29,36 +29,9 @@ using namespace lldb_private;
 
 class Pool {
 public:
-  /// The default BumpPtrAllocatorImpl slab size.
-  static const size_t AllocatorSlabSize = 4096 * 4;
-  /// Every Pool has its own allocator which receives an equal share of
-  /// the ConstString allocations. This means that when allocating many
-  /// ConstStrings, every allocator sees only its small share of allocations and
-  /// assumes LLDB only allocated a small amount of memory so far. In reality
-  /// LLDB allocated a total memory that is N times as large as what the
-  /// allocator sees (where N is the number of string pools). This causes that
-  /// the BumpPtrAllocator continues a long time to allocate memory in small
-  /// chunks which only makes sense when allocating a small amount of memory
-  /// (which is true from the perspective of a single allocator). On some
-  /// systems doing all these small memory allocations causes LLDB to spend
-  /// a lot of time in malloc, so we need to force all these allocators to
-  /// behave like one allocator in terms of scaling their memory allocations
-  /// with increased demand. To do this we set the growth delay for each single
-  /// allocator to a rate so that our pool of allocators scales their memory
-  /// allocations similar to a single BumpPtrAllocatorImpl.
-  ///
-  /// Currently we have 256 string pools and the normal growth delay of the
-  /// BumpPtrAllocatorImpl is 128 (i.e., the memory allocation size increases
-  /// every 128 full chunks), so by changing the delay to 1 we get a
-  /// total growth delay in our allocator collection of 256/1 = 256. This is
-  /// still only half as fast as a normal allocator but we can't go any faster
-  /// without decreasing the number of string pools.
-  static const size_t AllocatorGrowthDelay = 1;
-  typedef llvm::BumpPtrAllocatorImpl<llvm::MallocAllocator, AllocatorSlabSize,
-                                     AllocatorSlabSize, AllocatorGrowthDelay>
-      Allocator;
   typedef const char *StringPoolValueType;
-  typedef llvm::StringMap<StringPoolValueType, Allocator> StringPool;
+  typedef llvm::StringMap<StringPoolValueType, llvm::BumpPtrAllocator>
+      StringPool;
   typedef llvm::StringMapEntry<StringPoolValueType> StringPoolEntryType;
 
   static StringPoolEntryType &