Lua uses union GCObject to indicate all garbage collection objects:

GCObject
Lua uses union GCObject to indicate all garbage collection objects:

[Cpp]
182 /*
183 ** Union of all collectable objects
184 */
185 union GCObject {
186 GCheader gch;/* common header */
187 union TString ts;
188 union Udata u;
189 union Closure cl;
190 struct Table h;
191 struct protop;
192 struct UpVal uv;
193 struct lua_State th;/* thread */
194 };

182 /*
183 ** Union of all collectable objects
184 */
185 union GCObject {
186 GCheader gch;/* common header */
187 union TString ts;
188 union Udata u;
189 union Closure cl;
190 struct Table h;
191 struct protop;
192 struct UpVal uv;
193 struct lua_State th;/* thread */
194 };

This is equivalent to deriving all GC objects from GCheader in C ++, and they all share GCheader.

[Cpp]
74 /*
75 ** Common Header for all collectable objects (in macro form, to be
76 ** encoded ded in other objects)
77 */
78 # define CommonHeader GCObject * next; lu_byte tt; lu_byte marked
79
80
81 /*
82 ** Common header in struct form
83 */
84 typedef struct GCheader {
85 CommonHeader;
86} GCheader;

74 /*
75 ** Common Header for all collectable objects (in macro form, to be
76 ** encoded ded in other objects)
77 */
78 # define CommonHeader GCObject * next; lu_byte tt; lu_byte marked
79
80
81 /*
82 ** Common header in struct form
83 */
84 typedef struct GCheader {
85 CommonHeader;
86} GCheader;
The marked Flag is used to record some GC-related flags of the object. 0 and 1 are used to indicate the white state and spam state of the object. When the garbage collection mark stage ends, the remaining white object is the garbage collection object. Because lua does not immediately clear these junk objects, but gradually clears them step by step, these objects will still exist in the system for a period of time. In this case, we need to be able to distinguish between junk objects and non-junk objects in the white state. Lua uses two flags to represent white, which is used to efficiently solve this problem. This flag is used in turn as a white status sign, and the other indicates the garbage status. In global_State, A currentwhite is saved to indicate the flag used to Mark white. Every time the GC mark stage is complete, the system will switch this flag so that all the objects that were originally white do not need to be traversed and become spam objects, the real white object uses a new flag ID.

The first flag is used to indicate the black state, and neither the white nor the black is the gray state.

Except short string and open upvalue, all GCObject are connected to the allgc linked list in global state through next. We can traverse the allgc linked list to access all GCObject in the system. The short string is managed separately by the string label. Open upvalue is also connected to allgc when it is closed.

Reference relationship
In the garbage collection process, objects are identified by reference relationships between objects. The following lists the reference relationships between lua objects that need to be traversed during garbage collection:

All string objects, whether long or short, are not referenced by other objects.

The usedata object references a retriable and an env table.

The Upval object references a TValue through v, and then indirectly references an object through this TValue. In the open state, this v points to a TValue on the stack. In the close state, v points to the Upval TValue.

The Table object references other objects through key and value. If the array is partially valid, it is also referenced through the array. In addition, table references a retriable object.

Lua closure references the Proto object and uses the upvalues array to reference the Upval object.

C closure references other objects through the upvalues array. The upvalue here and the upvalue of lua closure are not exactly the same.

The Proto object references the names and constants generated during compilation and the Proto object embedded in this Proto.

The Thread object references other objects through the stack.

Barrier
As we said in principle, in the mark stage of incremental gc, barrier is required to ensure that "all black objects do not reference white objects.
Barrier is divided into two types: forward and backward.

The luaC_barrier _ function is used to implement the "Forward" barrier. "Forward" means to mark the white object immediately when a black object needs to reference a white object. In this way, the white object becomes a gray object, waiting for the next scan. This is to help gc identify a step forward. The luaC_barrier _ function is used in the following reference changes:

When the virtual machine is running, or use the api to modify the reference of close upvalue to other objects
Set the retriable reference of userdata or table through api
Set env table reference of userdata through api
References of the proto object to other compiled objects during the compilation and construction of the proto object
The luaC_barrierback _ function is used to implement the "backward" barrier. "Backward" means that when a black object needs to reference a white object, the black object that has been scanned is changed to a gray object again, waiting for a new scan. This is to move the gc mark back. Currently, luaC_barrierback _ is only used to monitor the changes in table key and value object references. Table is the most important data structure in lua, and even global variables are stored in a table. Therefore, table changes are frequent, in addition, the same reference may be repeatedly set to different objects. The reference to the table uses the Forward barrier to scan the changed objects one by one, which may cause a lot of unnecessary consumption. The barrier with "backward" is equivalent to dividing the table into two states: "Not changed" and "changed. Once a table is changed, it is converted to gray, waiting for a new scan. The table that is converted to gray does not matter no matter how many times the reference changes before it is re-scanned.

The number of thread objects that reference link changes most frequently. Thread references other objects through stack, and stack is continuously modified as the runtime stack. If you want to monitor these reference changes, it will definitely cause a serious reduction in execution efficiency. Therefore, lua does not add barriers to all stack reference changes, but directly assumes that the stack is changed. Therefore, even if the thread object is scanned, It is not set to black, but to gray again, waiting for another scan.

Upvalue
Processing Upvalue objects in garbage collection is special.
For open upvalue, its v points to the TValue on a stack, so the relationship between open upvalue and thread is very close. The reference to open upvalue can only be its affiliated thread and lua closure. If lua closure does not reference this open upvalue, even if it is referenced by the thread, it has no practical significance and should be recycled. That is to say, the reference of thread to open upvalue is completely a weak reference. Therefore, Lua does not regard open upvalue as an independent recyclable object. Instead, it submits the cleanup work to the subordinate thread object to complete the process. During the mark process, the open upvalue object only uses the white and gray States to indicate whether the object is referenced. From the reference relationship above, we can see that objects that may reference open upvalue may only be referenced by lua closure. Therefore, a gray open upvalue indicates that lua closure is currently referencing it, and this lua closure is not necessarily on the stack of this thread. In the cleaning phase, the thread object traverses all open upvalue from its own. If it is not gray, it indicates that there is no lua closure to reference this open upvalue and it can be destroyed.

When the syntax domain or thread that exits upvalue is destroyed, open upvalue is closed. All close upvalue and thread have no weak reference relationship, and will be converted into a common recyclable object, which is independent of other objects.