[LLVMdev] MmapAllocator

Reid Kleckner reid.kleckner at gmail.com
Mon Aug 9 14:05:49 PDT 2010

On Mon, Aug 9, 2010 at 1:42 PM, Ken Ferry <kenferry at gmail.com> wrote:
> On Sun, Aug 8, 2010 at 9:20 PM, Reid Kleckner <reid.kleckner at gmail.com>
> wrote:
>> On Sun, Aug 8, 2010 at 8:20 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>
>> wrote:
>> >
>> > On Aug 7, 2010, at 7:05 PM, Steven Noonan wrote:
>> >> I've been doing work on memory reduction in Unladen Swallow, and
>> >> during testing, LiveRanges seemed to be consuming one of the largest
>> >> chunks of memory.
>> >
>> > That's interesting. How did you measure this? I'd love to see your data.
>> >
>> > Note that the LiveRange struct is allocated by a plain std::vector, and
>> > your patch doesn't change that. I assume you are talking about the VNInfo
>> > structs?
>> Steven has been using Instruments, and sending us screenshots.  Does
>> anyone else know a better way of exporting that data?
> So, just so you're aware, direct calls to mmap are not intercepted and
> reported by Instruments.  So using mmap instead of malloc will make your
> _reported_ numbers go down, but that doesn't necessarily mean you have
> better performance.

I am aware.  We used Instruments mostly to drill down and find the
places that were doing the allocation.  The graphs generated by
perf.py use dirty pages.

> This is a problem for people doing performance measurements on Mac OS X and
> iOS, because exotic memory allocation schemes seem to be becoming more
> common (I hope not because they dodge reporting!).  In particular, may image
> buffers are allocated directly from mmap and vm_allocate, within
> CoreGraphics and elsewhere.

Yeah, it is kind of annoying that by doing this, we make it harder to
use Instruments to find problems.  :-/


More information about the llvm-dev mailing list