Android NDK: Dalvik Heap y Native Heap – Cómo separar entre los dos

Sé que hay montón de Dalvik (JVM) y montón nativo en una plataforma androide. Y el GC Dalvik no tiene trabajo en el montón nativo. Pero no estoy seguro de cómo este trabajo, me refiero a cómo el sistema operativo Android separarlos?

posible situación 1: compuesto por hardware de memoria independiente (no creo mucho)

posible situación 2: Android OS tiene cantidad FIJA de memoria para ambos montón

posible situación 3: Android OS tiene que asignar parte del montón de memoria Dalvik para convertirse en montón nativo cuando sea necesario, y por lo que el tamaño de montón nativo y montón Dalvik es flexible.

¿Cuál es la verdad, o posibilidad que no mencioné?

El montón nativo es administrado por dlmalloc() , que utiliza una combinación de mmap() y llamadas estándar como sbrk() para asignar memoria. El montón administrado ("Dalvik") es (en su mayoría) un fragmento grande asignado con mmap() . Todo se ejecuta en la parte superior del núcleo de Linux, por lo que si usted entiende la gestión de la memoria de Linux, ya sabes cómo funcionan las partes de bajo nivel.

Puede leer más acerca de cómo Dalvik devuelve páginas vacías de la pila administrada al sistema operativo en esta publicación .

Editar: la publicación canónica para obtener información sobre la gestión de la memoria de Android es ésta . No creo que responda directamente a su pregunta, pero tiene un montón de buena información y enlaces a sitios informativos.

Dado que Android es de código abierto, puede comprobar el código fuente usted mismo . Parece que llama create_mspace_with_base() . No estoy exactamente seguro de lo que hace, pero de acuerdo con este post , se asigna la memoria de /dev/zero .

Así que realmente está utilizando un montón "separado". Asigna directamente sus propias páginas de memoria y las gestiona por sí mismo.

Es casi su segundo caso

Hay dos heaps separados, uno para el runtime Art (previamente DalvikVM ) y uno para los programas native .

Usted puede ver fácilmente estas dos áreas diferentes mediante la realización de un cat en el pseudo-archivo de maps del sistema de archivos proc .

Considere la siguiente salida:

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

En el ejemplo anterior, la primera área, que sólo tiene una página, es administrada por el ART Runtime . Ambos dlmalloc y rosalloc son compatibles, pero ART utiliza rosalloc ya que es más rápido. Esta área, en contraste con lo que dijo @fadden (al menos para Lollipop), es gestionado por sbrk . Crece upwards .

La segunda área, que es 2048 páginas de largo, es el native heap . Es utilizado por la biblioteca bionic , que es una implementación de libc para Android. Ambos dlmalloc y jemalloc son compatibles, y el que se está utilizando depende del dispositivo. No he encontrado una llamada que extiende este montón, pero supongo que mmap sería suficiente. Crece downwards , hacia el montón de runtime .

  • ¿Hay de todos modos una aplicación puede utilizar más de 16mb en la memoria?
  • Android Universal Image Loader - ¿Cómo configuro las especificaciones correctamente?
  • Fuga de memoria a través de IClipboardDataPasteEventImpl
  • Memoria interna llena de imágenes, probablemente causada por Bitmap.compress (formato, int, flujo)
  • ¿Por qué el tamaño de mapa de bits es más grande en la memoria que en el disco en Android?
  • En el tecleo de lengüetas (botón de radio) Mi memoria que consigue el doble
  • Pruebas de Android onTrimMemory
  • ¿Por qué Rxjava podría causar fugas de memoria?
  • DDMS y OS muestran información de memoria diferente sobre mi aplicación
  • Fragmentos retenidos con IU y fugas de memoria
  • Borrar memoria caché de Picasso
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.