[llvm-commits] Changes to BumpPtrAllocator so it can be used for JITed function stubs and globals

Reid Kleckner rnk at mit.edu
Wed Jul 22 10:25:39 PDT 2009


On Tue, Jul 21, 2009 at 9:20 PM, Chris Lattner<clattner at apple.com> wrote:
>
> On Jul 21, 2009, at 2:09 PM, Reid Kleckner wrote:
>
>> I made some changes in response to djg's comments on IRC.
>> BumpPtrAllocatorBase now takes a template parameter for the slab
>> allocator, and BumpPtrAllocator just fills in the default malloc
>> allocator.  PTAL.
>
> Hi Reid,
>
> Some general comments:
>
> +++ include/llvm/Support/Allocator.h    (working copy)
> @@ -15,6 +15,9 @@
>  #define LLVM_SUPPORT_ALLOCATOR_H
>
>  #include "llvm/Support/AlignOf.h"
> +#include "llvm/Support/DataTypes.h"
> +#include "llvm/Support/raw_ostream.h"
> +#include <cassert>
>  #include <cstdlib>
>
> Allocator.h shouldn't depend on raw_ostream.
>
> A general comment about your patch: previously, the implementation details
> of the bump pointer allocator were nicely hidden in Allocator.cpp and the
> Allocator.h file was small and straight-forward.  Now, tons of guts are
> exposed. :(
>
> "Slab allocation" is relatively expensive anyway, so I don't see a problem
> with going through a virtual method to do it.  How about adding a very
> simple class like this:
>
> class SlabAllocator {
> public:
>  virtual MemSlab *Allocate(size_t Size) = 0;
>  virtual void Deallocate(MemSlab *Slab) = 0;
> };
>
> and give BumpPtrAllocator a "SlabAllocator*" that it allocates through?
>  This would allow the implementation of MallocSlabAllocator to be hidden
> completely in the .cpp file and allow the guts of BumpPtrAllocator to be in
> the .cpp file (and not be a template).  What do you think?

I think that's a great idea, and that's what I implemented first.  Dan
Ghoman suggested I templatize it.  Here is the un-templatized patch.

Reid
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SupportAllocatorPatch.diff
Type: text/x-diff
Size: 15368 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090722/4702a0fc/attachment.diff>


More information about the llvm-commits mailing list