Top N ++ things you need to know about Dalvik VM Memory Model

About the Dalvik VM memory model, you should know n implementation features

For the implementation of any Java virtual machine, memory management and garbage collection (Memory Model for short) are all important. Its implementation efficiency will largely determine the performance of virtual machines. This article will show you n implementation features of the Memory Model (DVM alloc) in DVM in the most concise way:

1. In DVM alloc implementation, there are two types of memory allocation: GC heap and native heap.

Their biggest difference is that the memory applied in the GC heap will eventually be reclaimed by the garbage collector. The memory in native heap is not managed by the garbage collector and must be explicitly released.

All Java objects are stored in GC heap, and they are applied for memory through the following functions (or functions that encapsulate them:

Void * dvmmalloc (size_t size, int flags) @ heap. cpp

Native heap is used to serve the implementation of DVM alloc. The cardtable and heapbitmap mentioned below apply for memory through malloc () or ashmem_create_region.

 

2. DVM has two built-in garbage collectors: Mark-clear garbage collection and copy garbage collection. The garbage collector is determined during compilation (whether the with_copying_gc compilation option is set), but cannot be dynamically switched during runtime.

 

3. DVM uses a separate memory (cardtable) to mark GC heap usage. Conceptually, the entire GC heap is divided into other large areas, each of which is gc_card_size. Each byte in cardtable represents a region.

When DVM is initialized, each byte in cardtable is initialized to the gc_card_clean (0x00) value, indicating that no content is written to the corresponding GC heap region. If the content in the following area is written, the corresponding cardtable byte will be marked as gc_card_dirty (0x70 ).

In this way, DVM can check whether the memory of the modified segment has been used in units of regions. For example, you do not need to search for objects in areas that have not been used during garbage collection.

 

4. DVM uses another independent memory (heapbitmap) to mark the status of Java objects in the memory. Heapbitpmap is an unsign long array (unsigned long * bits ). Each array member is called a word (word, unsign long type ).

In this model, we can divide the entire GC heap into regions with the size of hb_object_alignment (8). Each region is represented by a bit in heapbitmap.

For example, the highest bit (31st bits) of the first word in the heapbitmap array indicates a byte (hb_object_alignment long) of the GC heap, and the third bit indicates the second byte on the GC heap.

 

DVM uses two types of heapbitmap. One is livebitmap, which indicates the distribution of live objects in GC heap. If a Java object exists in an address in the memory (which must be aligned with hb_object_alignment), the corresponding bit in the heapbitmap is marked (set to 1 ).

Another kind of heapbitmap is markbitmap, which indicates the distribution of root nodes and highly accessible objects.

 

5. The tag-clear garbage collection algorithm uses livebitmap to traverse GC heap and mark all root nodes and all strongly accessible objects to mark markbitmap. In this way, all objects marked in livebitmap but not marked in markbitmap are junk.

 

6. The DVM memory model is not complex, but is implemented in layers. For example, alloc. in CPP, most functions simply call heap. the corresponding function in CPP, and heap. the functions in CPP call heapsource. CPP/marksweep. CPP (for Mark-sweep GC) or copying. implementation in CPP (for copying GC. The benefit of this layered model is to hide details to the maximum extent and increase the design flexibility. For example, the heap implementation function does not know whether Mark-sweep GC or copying GC is currently used. It calls the same interface. In this way, if we implement other GC algorithms in the future, we do not need to change the content above the heap layer.

7. A large number of accessors (vistor) are used in the DVM memory model ). The accessors traverse all elements in the same set and call the specified handler for each element. Different handler functions can be passed in for compilation to conveniently operate on each element of the same set to generate different behaviors.

8. DVM manages GC heap with the famous dlmalloc memory distributor. The author is Doug Lea.

9. We have not seen any amazing implementations of this model. All the technologies you can read can be referenced in other Java VM implementations.

The above is the conclusion of the rapid study of DVM alloc source code. Please do not give us any advice if there are any mistakes. The following are the challenges to everyone:

1. Implement your own garbage collector. The simpler the better! We recommend that you minimize the modification to other parts. The garbage collector should be able to compile and run.

2. dynamically switch between the flag-clear and copy garbage collectors in DVM.

3. Implement cardtable in a way that saves more memory

4. in actual use, it is found that the Mark-sweep garbage collector will generate very serious fragments of memory. Today, we can see an extreme example. It is clear that a VM instance still has 60% idle capacity (dozens of megabytes) but throws OOM when applying for a 200 + k memory. How can this problem be solved?

Haha, happy androiding!