[Lldb-commits] [PATCH] D71699: [lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates
This revision was automatically updated to reflect the committed changes.
Closed by commit rG500c324fa13e: [lldb] Increase the rate at which
ConstStrings memory allocator scales the… (authored by teemperor).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D71699/new/
https://reviews.llvm.org/D71699
Files:
lldb/source/Utility/ConstString.cpp
Index: lldb/source/Utility/ConstString.cpp
===
--- lldb/source/Utility/ConstString.cpp
+++ lldb/source/Utility/ConstString.cpp
@@ -29,9 +29,36 @@
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
+ Allocator;
typedef const char *StringPoolValueType;
- typedef llvm::StringMap
- StringPool;
+ typedef llvm::StringMap StringPool;
typedef llvm::StringMapEntry StringPoolEntryType;
static StringPoolEntryType &
Index: lldb/source/Utility/ConstString.cpp
===
--- lldb/source/Utility/ConstString.cpp
+++ lldb/source/Utility/ConstString.cpp
@@ -29,9 +29,36 @@
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
+ Allocator;
typedef const char *StringPoolValueType;
- typedef llvm::StringMap
- StringPool;
+ typedef llvm::StringMap StringPool;
typedef llvm::StringMapEntry StringPoolEntryType;
static StringPoolEntryType &
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
[Lldb-commits] [PATCH] D71699: [lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates
llunak accepted this revision. llunak added a comment. This revision is now accepted and ready to land. I'm back at using gdb for the time being, so I'd have to build code with debuginfo suitable for lldb, which would take some time. But given that this is more or less the same as I did before, I don't see why this shouldn't work similarly. Thank you for getting these changes in. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71699/new/ https://reviews.llvm.org/D71699 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D71699: [lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates
teemperor added a comment. (This patch is otherwise ready to land) Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71699/new/ https://reviews.llvm.org/D71699 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D71699: [lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates
teemperor added a comment. @llunak can you test how this affects your runtime for the use case you wanted this for? Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71699/new/ https://reviews.llvm.org/D71699 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D71699: [lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates
teemperor created this revision.
teemperor added a reviewer: llunak.
Herald added subscribers: lldb-commits, JDevlieghere, abidh.
Herald added a project: LLDB.
teemperor added a parent revision: D71654: [llvm] Add a way to speed up the
speed in which BumpPtrAllocator increases slab sizes.
We currently do far more malloc calls than necessary in the ConstString
BumpPtrAllocator. This is due to the 256 BumpPtrAllocators
our ConstString implementation uses internally which end up all just receiving
a small share of the total allocated memory
and therefore keep allocating memory in small chunks for far too long. This
patch fixes this by increasing the rate at which we increase the
memory chunk size so that our collection of BumpPtrAllocators behaves in total
similar to a single BumpPtrAllocator.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D71699
Files:
lldb/source/Utility/ConstString.cpp
Index: lldb/source/Utility/ConstString.cpp
===
--- lldb/source/Utility/ConstString.cpp
+++ lldb/source/Utility/ConstString.cpp
@@ -29,9 +29,36 @@
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
+ Allocator;
typedef const char *StringPoolValueType;
- typedef llvm::StringMap
- StringPool;
+ typedef llvm::StringMap StringPool;
typedef llvm::StringMapEntry StringPoolEntryType;
static StringPoolEntryType &
Index: lldb/source/Utility/ConstString.cpp
===
--- lldb/source/Utility/ConstString.cpp
+++ lldb/source/Utility/ConstString.cpp
@@ -29,9 +29,36 @@
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
