[llvm-commits] [PATCH] ArrayRecycler

[Michael Ilseman]

The patch looks reasonable to me. I have some ideas for tweaks in the future, but as you said they can hold off until further analysis and performance measurements.

+  /// Allocate an array of at least the requested capacity.
+  ///
+  /// Return an existing recycled array, or allocate one from Allocator if
+  /// none are available for recycling.
+  ///
+  template<class AllocatorType>
+  T *allocate(Capacity Cap, AllocatorType &Allocator) {
+    // Try to recycle an existing array.
+    if (T *Ptr = pop(Cap.getBucket()))
+      return Ptr;
+    // Nope, get more memory.
+    return static_cast<T*>(Allocator.Allocate(sizeof(T)*Cap.getSize(), Align));
+  }
+

Tweak idea: Allocate N number of objects all at once, so that we're building up our free pool when it's empty. N could even be a template parameter, defaulting to 1. This may not make sense for users that only want to use a BumpPtr allocator, though.

> - Recycle available arrays larger than the requested size by breaking them into smaller pieces. This could reduce memory usage at the risk of turning into malloc().

It would also reduce the number of reallocation calls. Again, that may not make sense if the primary use is with a BumpPtr.


On Jan 4, 2013, at 11:54 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

> Hi,
> 
> Please review this patch which adds an ArrayRecycler class to Support.
> 
> The class works a lot like the existing Recycler class, except it recycles arrays instead of single objects. Array capacities are picked from a small predetermined set, currently powers of 2.
> 
> This class will be used to manage the memory used for the MachineOperand lists on MachineInstrs. The purpose is to reduce malloc traffic, and to enable the pool allocation pattern. If MachineInstrs and MachineOperands are all allocated from the same BumpPtrAllocator, and if they have trivial destructors, a whole MachineFunction can be deallocated very quickly by simply zapping the BumpPtrAllocator.
> 
> I left out some features pending further analysis and performance measurements:
> 
> - Provide more small array sizes instead of just powers of 2. This would save some memory, but could cause more reallocations. (Part of the raison d'être of the Capacity class is to enable array size tinkering without changing clients).
> 
> - Recycle available arrays larger than the requested size by breaking them into smaller pieces. This could reduce memory usage at the risk of turning into malloc().
> 
> /jakob
> 
> <0001-Add-an-ArrayRecycler-class.patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits