search for: mmapallocator

On Aug 9, 2010, at 9:54 AM, Török Edwin wrote: > With mmap() it is always possible to fully release the memory once you > are done using it. Sure. Is that the goal, though? Why isn't malloc doing it already? > With malloc() no, it takes just 1 allocation at the end of the heap to > keep all the rest allocated. That wouldn't be a problem if libc would > use mmap() as the

...it > > doesn't. It uses sbrk() mostly for small (<128k) allocations, and > > even with mmaps it caches them for a while. > > Recommended reading: > http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf If jemalloc provides same or better memory usage than MMapAllocator, I think it'd be better to have a JEMallocAllocator instead. I think jemalloc is fairly portable (firefox uses it), isn't it? > > > I think that is because mmap() is slow in multithreaded apps, since > > it needs to take a process level lock, which also contends with the &g...

...uses sbrk() mostly for small (<128k) allocations, and >> > even with mmaps it caches them for a while. >> >> Recommended reading: >> http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf > > If jemalloc provides same or better memory usage than > MMapAllocator, I think it'd be better to have a JEMallocAllocator > instead. > I think jemalloc is fairly portable (firefox uses it), isn't it? Reading the abstract, jemalloc seems like it has nothing to do with keeping the total heap usage low and everything to do with performance in a multithrea...

On Mon, 9 Aug 2010 09:36:53 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Aug 8, 2010, at 9:20 PM, Reid Kleckner wrote: > > > I thought I dug into the register allocation code, and found the > > VNInfo::Allocator typedef. I assumed that was getting the traffic > > we saw in Instruments, but I don't have the data to back that up. > >

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

On Aug 8, 2010, at 9:20 PM, Reid Kleckner wrote: > I thought I dug into the register allocation code, and found the > VNInfo::Allocator typedef. I assumed that was getting the traffic we > saw in Instruments, but I don't have the data to back that up. Are you using llvm from trunk? VNInfo is a lot smaller now than it was in 2.7. I would guess about a third of the liveness memory

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

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

Hi Steven- Nice, but will this not break Windows? From an initial glance over your patch, it seems to assume the existence of mmap() in some form or other. Alistair On 8 Aug 2010, at 03:05, Steven Noonan wrote: > Hi folks, > > 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

Hi folks, 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. I wrote a replacement allocator for use by BumpPtrAllocator which uses mmap()/munmap() in place of malloc()/free(). It has worked flawlessly in testing, and reduces memory usage quite nicely in Unladen Swallow. The code is available