Hi Geoffrey, On Wed 02 Oct 2013 00:11, Geoffrey Garen <gga...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
