A brief explanation of the garbage collection mechanism in LUA

This article mainly introduces the garbage collection mechanism in Lua, automatic garbage collection is one of the important features of LUA, the need for friends can refer to the

LUA uses garbage collection automatic memory management based on some algorithms built into Lua. Can automate the results of memory management as a developer:

There is no need to worry about allocating memory for objects.

It is no longer necessary to set them as nil without releasing them.

Lua no longer accesses the garbage collector from the LUA program when it uses the objects that are collected from the runtime.

All objects, including tables, user data, functions, threads, strings, etc. are subject to automatic memory management. Lua cleans up collectors with incremental markup and by using two digits to control their garbage collection cycle, that is, garbage collector pauses and garbage collector steps. These values are in percentages and 100 of values are often equal to 1.

Garbage collection paused

Garbage collection pauses are used to control how long the garbage collector needs to wait before it is called again by Lua's automatic memory management. A value below 100 means that LUA does not wait for the next cycle. A similarly high value of this value will cause the garbage collector to be slow and less aggressive in nature. 200 indicates that the total memory waiting for the collection is twice times before the start of a new cycle in use. Therefore, depending on the nature and speed of the application, it may be necessary to change the value to obtain the best performance in LUA applications.

The garbage collector steps with a multiplier

This step multiplier controls the relative speed of garbage collection in the memory allocation of the LUA program. A larger step value will cause the garbage collector to be more aggressive, while also increasing the size of each incremental step in the garbage collection. A value of less than 100 may often lead to avoidance of garbage collectors not completing its cycle and its general not optimal. The default value is 200, which means that the garbage collector runs twice times the speed of memory allocation.

Garbage collector functions

As a developer, we did have the automatic memory management for LUA. To do this, there are several ways.

CollectGarbage ("collect"): Performs a complete cycle of garbage collection.

CollectGarbage ("Count"): Returns the amount of memory in kilobytes currently in use

CollectGarbage ("restart"): If the garbage collector has stopped, it will be restarted.

CollectGarbage ("Setpause"): Sets the value given to the second parameter divided by 100 to the garbage collector pause variable. Its use is as a point of discussion above.

CollectGarbage ("Setstepmul"): Sets the value of a variable given as the second parameter divided by 100 to the garbage step multiplier. Its use is as a point of discussion above.

CollectGarbage ("Step"): Steps to run a garbage collection. The second argument is that the bigger the step, the bigger the step. The garbage collected will return true if the triggered step is the last step of a garbage collection cycle.

CollectGarbage ("Stop"): Stop the garbage collector if it's running.

Using the garbage collector for example, a simple example is shown below.

The code is as follows:

MyTable = {"Apple", "orange", "Banana"}

Print (CollectGarbage ("Count")

MyTable = Nil

Print (CollectGarbage ("Count")

Print (CollectGarbage ("collect"))

Print (CollectGarbage ("Count")

When we run the above program, we get the output below. Note that this can be a different result because the LUA automatic memory management feature may be different in the operating system.

The code is as follows:

20.9560546875

20.9853515625

0

19.4111328125

You can see from the above program that once the garbage collection is complete, you can reduce the use of memory. But it is also not a mandatory invocation. Even if we do not call it, it will automatically be executed by the LUA interpreter at the latter stage after the scheduled time.

Obviously we can change if we need to use these functional behaviors of the garbage collector. These features provide a little extra capacity for developers to handle complex situations. This feature may or may not be used, depending on the type of memory needed to execute the program. But in the application's memory usage, and in the program itself, to avoid having to check the results after deployment.