search for: jemallocalloc

...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 > > lock taken by pagefaults from other existing...

..., 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 multithreaded app. >> > I think that is because mmap...

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

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. > >