Android NDK: Dalvik Heap and Native Heap - How Separate Between the two

Question

I know there's Dalvik(JVM) heap and Native heap in an android platform. And the Dalvik GC has no work on native heap. But I'm not sure how this work, I mean how the Android OS separate them?

possible situation 1: composed by separate memory hardware (I don't believe much)

possible situation 2: Android OS has FIXED amount of memory for both heap

possible situation 3: Android OS has to allocate part of Dalvik memory heap to become native heap when necessary, and so the size of native heap and Dalvik heap is flexible.

Which one is true, or possibility that I didn't mention?

Answer 1

The native heap is managed by dlmalloc() , which uses a combination of mmap() and standard calls like sbrk() to allocate memory. The managed ("Dalvik") heap is (mostly) one large chunk allocated with mmap() . It's all running on top of the Linux kernel, so if you understand Linux memory management then you already know how the lower-level parts work.

You can read more about how Dalvik returns empty pages from the managed heap to the OS in this post .

Edit: the canonical post for information about Android memory management is this one . I don't think it directly answers your question, but it has a lot of good information and links to informative sites.

Answer 2

Since Android is open source, you can check out the source code yourself . Looks like it calls create_mspace_with_base() . I'm not exactly sure what that does, but according to this post , it maps memory from /dev/zero .

So it really is using a "separate" heap. It allocates its own memory pages directly and manages that itself.

Answer 3

It is almost your second case

There are 2 separate heaps , one for the runtime Art (previously DalvikVM ), and one for the native programs.

You can easily see these two different areas by performing a cat on the maps pseudo-file of the proc filesystem.

Consider the following output:

2a028000-2a029000 rw-p 00000000 00:00 0          [heap]
b6400000-b6c00000 rw-p 00000000 00:00 0          [anon:libc_malloc]

In the above example, the first area, that is only 1 page long, it is managed by the ART Runtime . Both dlmalloc and rosalloc are supported, but ART uses rosalloc since it is faster. This area, in contrast to what @fadden said (at least for Lollipop), is managed by sbrk . It grows upwards .

The second area, that is 2048 pages long, it is the native heap . It is used by the bionic library, which is an implementation of libc for Android. Both dlmalloc and jemalloc are supported, and the one that it is being used depends on the device. I haven't found a call that extends this heap, but I guess mmap would suffice. It grows downwards , towards the runtime heap.