[webkit-dev] WTF::fastMalloc

[Andy Wingo]

Hi Geoffrey,

On Wed 02 Oct 2013 00:11, Geoffrey Garen <ggaren at apple.com> writes:

> There are two problems with the current OSAllocator POSIX implementation:
>
> (1) It uses mmap, which doesn’t support aligned allocation. To get
> aligned allocation, POSIX double-allocates all virtual memory. That is
> 2X too much. So, we need to find a variation on mmap that supports an
> alignment constraint.

This doesn't exist on POSIX, as you probably know.  posix_memalign
doesn't have the zeroing characteristics of anonymous mmap, and is
otherwise a terrible interface.  Darwin-like vm_map and friends would be
nicer.

However, given the constraints, what's the problem with the mmap
strategy?  Sure, you have more page tables on the kernel side, but
mmap'd memory that is never touched is never resident in a process.  I
verified this a few months back when troubleshooting some memory-related
issues.

> (2) POSIX uses MADV_FREE, MADV_DONTNEED, and/or MADV_WILLNEED. I don’t
> think anybody has ever verified that these APIs do what we want. In my
> experience, they usually don’t. So, we need to find a variation on these
> APIs that works and is fast.

I've looked into it.  The MADV_WILLNEED is useless -- it does nothing on
anonymous pages, returns -EINVAL, but is harmless also.  The
MADV_DONTNEED dance does work though, properly paging out memory and
lazily providing fresh zeroed pages should the memory be paged in again.

> We need somebody to resolve these issues, otherwise our memory
> footprint will be unacceptably high, and/or our VM operations will be
> unacceptably slow.

There is no memory footprint problem caused by mmap here -- to my
knowledge.  I don't know how to profile the VM overhead, though.

I will agree that OSAllocatorPosix.cpp is exceptionally ugly ;), but it
does seem to do its job within reasonable performance constraints.

Regards,

Andy