[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