[PATCH] BumpPtr allocate SimpleReferences

Rui Ueyama ruiu at google.com
Thu Dec 4 14:18:14 PST 2014


I was thinking that Colin has suggested to store pointers to the vector
instead of the object itself.

I think the patch is good to land. There seems to be other ways to do the
same thing, but the code is mostly at one place, so we can revisit this
topic if we need to. This patch wouldn't harm anyone who doesn't touch this
code.

And the memory leak is a real issue which has to be resolved.

On Thu, Dec 4, 2014 at 2:02 PM, kledzik at apple.com <kledzik at apple.com> wrote:

> Colin's calculation is based on the bumpvector containing only the
> *pointer* to the Reference. The current implementation has a vector<
> SimpleReference>, so the wasted space is not just a pointer size
> (repeatedly doubled).  A SimpleReference is 64 bytes in size, so that value
> keeps getting doubled (and wasted).
>
> Even if we switched to using a bumpvector for a pointer to reference, we
> still need to allocate the SimpleReference body somewhere.
>
> For Atoms and References, the best allocator is a BumpPtr allocator.
> Because, 1) Atoms (and References) are owned by their File and ownership
> never changes, 2) they are never destructed (until the File is
> destructed).  If either of those was false, then we could not use  BumpPtr.
>
> The reason for this patch is because the current SimpleDefinedAtom has an
> embedded vector which means SimpleDefinedAtom (and subclasses) cannot be
> BumpPtr allocated (without leaking).  If we don't want to change
> SimpleDefinedAtom, I can change MachODefinedATom to not subclass
> SimpleDefinedAtom.
>
> http://reviews.llvm.org/D6518
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141204/f76b18c4/attachment.html>


More information about the llvm-commits mailing list