Android NDK: куча Dalvik и родная куча - как отдельно между двумя

Я знаю, что куча Dalvik (JVM) и Родная куча на платформе Android. И в Dalvik GC нет работы на родной куче. Но я не уверен, как эта работа, я имею в виду, как ОС Android их разделяет?

Возможная ситуация 1: составлена с помощью отдельного аппаратного обеспечения памяти (я мало верю)

Возможная ситуация 2: ОС Android имеет FIXED количество памяти для кучи

Возможная ситуация 3: ОС Android должна выделять часть кучи памяти Dalvik, чтобы стать родной кучей, когда это необходимо, и поэтому размер нативной кучи и кучи Dalvik является гибким.

Какое из них истинно или возможность, о которой я не упоминал?

Ответ 1

Нативная куча управляется dlmalloc(), которая использует комбинацию mmap() и стандартных вызовов, таких как sbrk() для выделения памяти. Управляемая ( "Dalvik" ) куча (в основном) - один большой кусок, выделенный mmap(). Все это работает поверх ядра Linux, поэтому, если вы понимаете управление памятью Linux, вы уже знаете, как работают детали нижнего уровня.

Вы можете узнать больше о том, как Dalvik возвращает пустые страницы из управляемой кучи в ОС в этом сообщении.

Изменить: канонический пост для информации об управлении памятью Android - этот. Я не думаю, что он напрямую отвечает на ваш вопрос, но он имеет много хорошей информации и ссылок на информационные сайты.

Ответ 2

Поскольку Android является открытым исходным кодом, вы можете проверить исходный код самостоятельно. Похоже, он называет create_mspace_with_base(). Я не совсем уверен, что это делает, но согласно этот пост, он отображает память из /dev/zero.

Таким образом, он действительно использует "отдельную" кучу. Он сам выделяет собственные страницы памяти и сам управляет этим.

Ответ 3

Это почти ваш второй случай

Существует 2 отдельных heaps, один для runtime Art (ранее DalvikVM) и один для программ native.

Вы можете легко увидеть эти две разные области, выполнив cat в псевдо файле maps файловой системы proc.

Рассмотрим следующий вывод:

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

В приведенном выше примере первая область, длина которой составляет всего одну страницу, управляется ART Runtime. Поддерживаются как dlmalloc, так и rosalloc, но Art использует rosalloc, поскольку он быстрее. Эта область, в отличие от того, что сказал @fadden (по крайней мере для Lollipop), управляется sbrk. Он растет upwards.

Вторая область, то есть 2048 страницы длинная, это native heap. Он используется библиотекой bionic, которая представляет собой реализацию libc для Android. Поддерживаются как dlmalloc, так и jemalloc, и тот, который он используется, зависит от устройства. Я не нашел вызов, который расширяет эту кучу, но я думаю, mmap хватит. Он растет downwards, к куче runtime.