What special powers does ashmem have?

Question

Can someone explain why ashmem was created?

I'm browsing through mm/ashmem.c right now. As near as I can tell, the kernel is thinking of ashmem as file-backed memory that can be mmap'd. But then, why go to the trouble of implementing ashmem? It seems like the same functionality could be achieved by mounting a RAM fs and then using filemap/mmap to share memory.

I'm sure that ashmem can do more fancy stuff -- from looking at the code, it seems to have something to do with pinning/unpinning pages?

Answer 1

Ashmem allows processes which are not related by ancestry to share memory maps by name, which are cleaned up automatically.

Plain old anonymous mmaps and System V shared memory lack some of these requirements.

System V shared memory segments stick around when no longer referenced by running programs (which is sometimes a feature, sometimes a nuisance).

Anonymous shared mmaps can be passed from a parent to child processes, which is inflexible since sometimes you want processes not related that way to share memory.

Answer 2

Can someone explain why ashmem was created?

David Turner (a regular on Android NDK) answered this in Why was bionic/libc/include/sys/shm.h removed?:

... System V IPCs have been removed for cupcake. See bionic/libc/docs/SYSV-IPC.TXT for details.

In brief, System V IPCs are leaky by design and do not play well in Android's runtime environment where killing processes to make room for other ones is just normal and very common. The end result is that any code that relies on these IPCs could end up filling up the kernel's internal table of SysV IPC keys, something that can only safely be resolved by a reboot.

We want to provide alternative mechanism in the future that don't have the same problems. One thing we provide at the moment is ashmem, which was designed specifically for Android to avoid that kind of problem (though it's not as well documented as it should). We probably need something similar for semaphores and/or message queues.