[llvm-commits] [unladen-swallow] Re: Patch to allow the JITMemoryManager to allocate more blocks of memory
Evan Cheng
evan.cheng at apple.com
Mon Jul 13 22:37:18 PDT 2009
Hi Reid,
Thanks. A couple of comments.
Can you change CheckInvariants() to return true / false and the error
message by reference instead?
+ /// BumpAllocator - This is a simple memory allocator that simply
bumps a
+ /// pointer forwards across a slab of memory until it runs out, at
which
+ /// point it allocates a new slab. If the size of an allocation is
above a
+ /// certain threshold, the allocator allocates a separate slab for
it, to
+ /// avoid wasted space. We use this class to allocate function
stubs and
+ /// global data structures.
+ class BumpAllocator {
Is there a reason not to use the BumpPtrAllocator in Support/
Allocator.h?
+ for (MemoryRangeHeader *Hdr = (MemoryRangeHeader*)Start, *LastHdr
= NULL;
+ Start <= (char*)Hdr && (char*)Hdr < End;
+ Hdr = &Hdr->getBlockAfter()) {
+ if (Hdr->ThisAllocated == 0) {
How about "if (!Hdr->ThisAllocated) continue;" to reduce indentation.
Thanks,
Evan
On Jul 13, 2009, at 4:57 PM, Reid Kleckner wrote:
> On Tue, Jun 23, 2009 at 11:11 PM, Chris Lattner<clattner at apple.com>
> wrote:
>> Have you run through the llvm testsuite with the initial threshold
>> cranked
>> way down? This would cause the test suite to check out whether the
>> reallocation stuff is working. If that works, it looks good to me.
>
> So, getting back to this patch, I went ahead and did all the FIXMEs in
> JITMemoryManager.cpp. This means that it will not run out of memory
> for function stubs, global data, or code until the OS gives up.
>
> I've added some unit tests which now pass, and the SPASS test passes
> with lli. I had to modify lli to not allocate globals with code,
> though, but I think that should eventually become the default. I'm
> running the rest of the nightly tests right now.
>
> I've attached the patch and here's the Rietveld link if you prefer:
> http://codereview.appspot.com/71042/show
>
> Here's a description of how the patch works:
>
> For stubs and global data, the memory manager uses the simple
> BumpAllocator class, which keeps a vector of memory slabs and a pair
> of pointers that it bumps along to make allocations. For especially
> large allocations, it allocates a separate slab. This is done so that
> in the worst case it wastes at most an amount of space equal to the
> threshold at the end of the block, or a page at the end of the
> separate slab.
>
> For code, the memory manager adds the ability to request more memory
> by allocating more code slabs and adding them to the free list. If
> memory gets fragmented, this could become a problem, since each
> allocation loops over the entire free list.
>
> When the JITEmitter runs out of space in the buffer it got on its
> first try, it now frees the memory it has been working with so far,
> asks for twice as much memory, and tries again until it succeeds.
>
> Please review!
>
> Thanks,
> Reid
> <JITMemoryManager.diff>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
More information about the llvm-commits
mailing list