[llvm-commits] [llvm] r151834 - in /llvm/trunk: lib/Support/Allocator.cpp unittests/Support/AllocatorTest.cpp

Argyrios Kyrtzidis kyrtzidis at apple.com
Thu Mar 1 14:21:27 PST 2012


On Mar 1, 2012, at 1:19 PM, Chris Lattner wrote:

> On Mar 1, 2012, at 1:14 PM, Argyrios Kyrtzidis wrote:
>>>> void *BumpPtrAllocator::Allocate(size_t Size, size_t Alignment) {
>>>> +  // 0-byte alignment means 1-byte alignment.
>>>> +  if (Alignment == 0) Alignment = 1;
>>>> +
>>>> +  size_t PaddedSize = Size + sizeof(MemSlab) + Alignment - 1;
>>>> +
>>>> +  // If requested size exceeds slab size, increase slab size.
>>>> +  while (PaddedSize > SlabSize)
>>>> +    SlabSize *= 2;
>>> 
>>> Have you measured that this doesn't make us waste a ton of memory?
>> 
>> Without my change BumpPtrAllocator will just corrupt memory when "PaddedSize > SlabSize"; do you have an alternative way in mind to handle this ?
> 
> Why not have it just handle "allocation request greater than the slab size" as doing a separate allocation just for that request (and tracking it as a slab) but not changing the slab size?
> 
> Given an allocation pattern like:
> 
> alloc(4)
> alloc(4)
> alloc(4)
> alloc(40000000)
> alloc(4)
> 
> It would be nice to have this end up as two slabs: the initial one and the one very-large one.

In such extreme pattern indeed just one slab is nice; I had in mind the case where you think that in the majority of cases the slabs are fine to have a certain size, but then you come into a situation where bigger chunks are going to be requested.


> 
> -Chris




More information about the llvm-commits mailing list