MMgc: The Garbage Collector of Flash Player

MMgc is the memorymanagementgarbagecollector used in Flash Player. MMgc is used not only to recycle objects in the ActionScript, but also to manage all dynamic memory allocation and release requests in Flash Player, in the C ++ code of Flash Player VM, many objects are handed over to MMgc for automatic recovery. Therefore, theoretically, MMgc can be separated from the Flash Player Code and used as a separate GC library for all C ++ programs.
In MMgc, objects on the stack are divided into two types: Managed and UnManaged. Managed is Managed by the GC. You only need to use new instead of delete, but you can also manually delete it. UnManaged is the objects in the traditional C ++ and must be manually new/delete.
All Managed objects must be inherited from class GCObject (or its subclass. This class adds the new and delete methods:
Class GCObject {
Static void * operator new (size_t size, GC * gc, size_t extra );
Static void * operator new (size_t size, GC * gc );
Static void operator delete (void * gcObject );
};
Assume that a class is inherited from GCObject, for example
Class MyPoint2D: public MMgc: GCObject {
Int x;
Int y;
};
Then we can use new directly as before:
MyPoint2D * p = new MyPoint2D (); // the object is not managed by GC.
You can also pass a gc object to new: www.2cto.com.
MyPoint2D * p = new (gc) MyPoint2D (); // The resulting object is managed by GC. Delete not required
The following syntax looks like new with placeholder, but it is not.
From the Managed object to the Managed object, add a write barrier called DWB.
Class mythermanagedobject: public MMgc: GCObject {DWB (MyPoint2D *) object ;};
For objects not managed by GC, either it has nothing to do with GC, such as std: string. Or, if it contains a pointer to the Managed object, the class must inherit from GCRoot:
Class MyUnmanagedObject: public MMgc: GCRoot {MyPoint2D * point ;};
As the name suggests, these objects on the demarcation points are the starting point of GC. Mark-sweep from these objects during GC execution.
However, this is not enough. If the type of a member variable is a pointer and the pointer points to a Managed object, a write barrier must be added. That is, the preceding example must be changed:
Class MyUnmanagedObject: public MMgc: GCRoot {DRC (MyPoint2D) * point ;};
For other types, do not add:
Class MyUnmanagedObject: public MMgc: GCRoot {DRC (MyPoint2D) * point; std: string * name ;};
This is also the issue of destructor. As we all know, JAVA and other languages with GC do not have destructor. You must use the finalize method. In this regard, the practice of MMgc is to change the base class from GCObject to GCFinalizedObject.
GCFinalizedObject also has a subclass called RCObject. This object will contain a field of the uint32_t type for reference counting. Once count to 0, it will be free immediately. In this way, the memory is released more instantly, thus reducing the GC pressure. However, write barriers must be changed from DWB to DRCWB.
In addition, for RCObject objects, all member variables must be cleared by 0 in its destructor.
Therefore, although MMgc is used to avoid manual delete, there are also many risks of errors, such:
1. Use the write barrier error. DWB, DRCWB, and DRC are written incorrectly or missing, or are not added.
2. unmanaged object does not inherit from GCRoot.
However, these problems are easy to find during the compilation period. You can check the definition of the class.
MMgc now has two sets of implementations: conservative gc and exact gc. One problem with conservative gc is that it cannot accurately judge pointers and integers. Therefore, if an int happens to have a value equal to the address of an object, the object will be referenced falsely and cannot be released. However, Adobe's idea is that this is not a big problem. This is because the probability of such events is very random, so it will not lead to a sudden increase in memory. Www.2cto.com
The preceding DRC macro, in which DRC is short for Deferred Reference Counting. Deferred means that it is not immediately cleared when it reaches 0. This is because GC only manages the stack. If a pointer on the stack points to this object, GC does not know. The RCObject object with count = 0 will be put in a Table called Zero Count Table (ZCT), and then find the reference relationship by backtracking the entire stack as appropriate, then, clear unused ones.
Flash VMS are already open-source, called tamarin, managed by the Mozilla Foundation. It contains all the code of MMgc. I tried to separate MMgc, but it was not easy. Because MMgc depends not only on the following OS adaptation layer, but also on some code (String, Math, Date) in the VM core. It may be better to remove memory profiler.
I thought about it later. It is not easy for other programs to use MMgc, because MMgc is single-threaded. At present, there are fewer and fewer single-threaded programs.