Android dalvik heap management, androiddalvik

Android dalvik heap management, androiddalvik

Recently I encountered a dalvik memory-related problem. I have some knowledge about the heap Management of dalvik. Here I will summarize the following three aspects:
1. The implementation of java heap is different from that of native heap.
2. gc implementation.
3. Configure the meaning of prop related to heap.

Davlik java heap

Java heap is generally independent from Native heap. Because java object collection involves scanning the entire memory, native and java are not managed together.
The heap related to dalvik has the following key classes. DvmGlobals has a global object gDvm, which is a key object in davlik. The global information is stored here.

You can see that the heap is created mainly in the dvmHeapSourceStartup () function by following the following steps:
1. mmap maps the memory (according to the maximum heapsize) to the current process (function dvmAllocRegion ()).
2. Assign the mmap address to dlmalloc for Management (through the mspace interface, create_mspace_with_base (). Initially, only the startSize memory is allocated to dlmalloc for management.
3. Call addInitialHeap () to create the current Heap object.

From the code, we can see that the management of java heap and native heap is indeed independent, and java heap does not directly use the libc library, but instead mmap a piece of memory separately, using the other set of dlmalloc
API to manage applications and release applications.

In addition, we know from the code that there are two Heap in HeapSource. The first Heap creates a heap in dvmHeapSourceStartup, and the other is to call addNewHeap () in the dvmHeapSourceStartupBeforeFork () function () A new Heap object is created.
The problem is, why do we need to establish two Heap instances? From the Heap structure, a heap is enough to express all the information. This issue will be discussed later.

GC

Dalvik adopts the gc policy mark-sweep.
In simple terms, the mark-sweep mechanism is to scan all objects and divide them into accessible and inaccessible objects. Inaccessible objects are the objects to be recycled.

HeapBitmap
During gc, we should first consider how to record all the objects and then check their accessibility.
In dalvik, HeapBitmap is used for implementation. Each bit in HeapBitmap corresponds to an 8 bytes chunk on the java heap. Whether the bit on HeapBitmap is 1 or 0 indicates whether the memory on the corresponding Heap corresponds to a java object. Based on this, the system checks the accessibility of all objects.
HeapBitmap is initialized by calling dvmHeapBitmapInit () in dvmHeapSourceStartup (). Its memory is also mapped through mmap.

LiveBits & markBits
During gc, two HeapBitmap objects are operated: gHs-> liveBits and gHs-> markBits.
LiveBits is used to record all existing Java objects. when an object is applied, set the corresponding bit to 1 (countAlloction ()), when you free an object, set its corresponding bit to 0 (countFree ()).
MarkBits is used as a local variable. At the beginning of each gc, all bits are 0, scan all root objects to record all accessible objects (set the corresponding markBits to 1 ).
Then compare liveBits and markBits. The values of liveBits are 1, and the values of 0 in markBits are the java objects to be recycled.

Why need two Heaps in HeapSource?
Now let's look back at why there are two Heap objects in heapSource?
In the gc process, we can see that the gc spec has an isPartial condition, indicating whether the gc only performs partial gc to reduce the waiting time (isPartial will be set during gcForMalloc ). The partial here is to scan only the memory corresponding to heap [0] in the current HeapSource, instead of checking the memory corresponding to heap [1, the bits corresponding to this part of memory is directly copied from liveBits to markBits.
In addition, from the perspective of the time when two heap instances were created, for general apps, the first heap was used mainly for preload class and resource in zygote, which is relatively fixed in memory, the second heap is created before the fork app, and the application for release of this part of memory is frequent, when partical is used, the second heap can be recycled to produce a large amount of memory.

 

Heap configuration prop

Dalvik. vm. heapsize
The maximum size of the Java heap, which determines the size of the memory in the mmap when the heap is created.
For applications, it is the upper limit of heap.

Dalvik. vm. heapstartsize
The size of the first heap created during dvm startup is generally not large. It is mainly for zygote to perform preload. This value is meaningless for the app.
The online saying is that this is the size of the first heap used for the app. Actually, it is incorrect. When the app is started, both heaps have been created.

Dalvik. vm. heapgrowthlimit
This value is the default upper limit (including the size of the first heap) when the second heap is created. This value can be larger and can meet the needs of General apps as much as possible, but for small memory
The machine should be as small as possible to save memory.
If the android: largeHeap = true attribute is set for some apps, The growthlimit is invalid because it is equal to heapSize (see dvmClearGrowthLimit ()).

Dalvik. vm. heaptargetutilizatio, dalvik. vm. heapminfree, dalvik. vm. heapmaxfree
We mentioned earlier that java heap first generates a memory (virtual memory, which does not point to physical memory) from mmap in/dev/zero, and then gradually delivers the memory to dlmalloc for management.
The three prop values are related to the process. A softlimit value is set together with the three values (see the setIdealFootprint () function) to ensure heap usage as much as possible, so that the memory will not be wasted. When the memory is applied for each time, if softlimit is reached, gc will be performed first. If gc is not guaranteed, to expand the memory area managed by dlmalloc (see dvmHeapSourceAllocAndGrow ()).
The meaning of the three prop can be understood as follows:
Heaptargetutilization is the ideal memory usage (malloc_size/cur_heap_size) managed by dlmalloc)
Maxfree is the free memory available to the most memory managed by dlmalloc.
Minfree is the free memory required by the minimum amount of memory managed by dlmalloc.

What files are in the data \ dalvik-cache folder of the Android phone?

Literally, it is the cache folder of dalvik.

The information found is as follows:
Single point of view: Dalvik is another important part of the Android system, including virtual machines and a set of important runtime environments. It is a well-designed underlying application of a mobile phone terminal.
Reference: Baidu Knows

How to solve Android memory overflow

The simulator RAM is relatively small and only has 8 MB of memory. When I put a large number of images (about 100 K each), the above problem occurs. Since each image was previously compressed. When it is placed into Bitmap, the size will increase, resulting in the memory exceeding the RAM. The specific solution is as follows: // solve the problem of image memory overflow loading. // Options only saves the image size, do not save the image to the memory BitmapFactory. optionsopts = newBitmapFactory. options ();/* scale ratio. It is difficult to scale according to the prepared ratio. The value indicates the zoom factor. In the SDK, it is recommended that the value be a constant of 2, the larger the value, the image is not clear */opts. inSampleSize = 4; Bitmapbmp = null; // reclaim bmp. recycle (); you can also use the heap memory allocation optimization for the Dalvik Virtual Machine. For the Android platform, the DalvikJavaVM used by its hosting layer can be optimized from the current performance, for example, when developing large game or resource-consuming applications, we may consider Manual Interference with GC and use dalvik. system. set provided by the VMRuntime class The TargetHeapUtilization method can improve the processing efficiency of the program heap memory. Of course, we can refer to open-source projects for specific principles. Here we only talk about the usage method: privatefinalstaticfloatTARGET_HEAP_UTILIZATION = 0.75f; VMRuntime can be called during onCreate. getRuntime (). setTargetHeapUtilization (TARGET_HEAP_UTILIZATION, in addition to optimizing the heap memory allocation of the Dalvik virtual machine, we can also forcibly define the memory size of our software. We use the Dalvik provided by dalvik. system. for example, privatefinalstaticintCWJ_HEAP_SIZE = 6*1024*1024; VMRuntime. getRuntime (). setMin ImumHeapSize (CWJ_HEAP_SIZE); // set the minimum heap memory to 6 MB. Of course, for memory compression, manual GC interference can also be performed.