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 & _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
