Lua uses automatic memory management based on garbage collection that is built into Lua's algorithms. Can automatically manage the results of memory as a developer:
- There is no need to worry about the allocation of memory of objects.
- When they are not required to be released, they can no longer be set to nil.
Lua uses the garbage collector no longer accesses from the Lua program when it is running to collect dead objects from time to time.
All objects, including tables, user data, functions, threads, strings, etc., are subject to automatic memory management. Lua uses incremental marking and uses two numbers to control its garbage collection cycle i.e. garbage collection pause and garbage collector steps to clean up the collector with half the effort. These values are in percentage and the value of 100 is often equal to 1.
Garbage collection is suspended
Garbage collection pause is 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 will not wait for the next cycle. A similarly higher value of this value will result in the garbage collector being slow and less aggressive in nature. 200 indicates that the total memory waiting for the set exists twice before the start of a new cycle. Therefore, depending on the properties and speed of the application, it is possible to require changing this value to obtain the best performance in Lua applications.
The steps of the garbage collector are twice the result with half the effort
This step multiplier controls the relative speed of garbage collection in the memory allocation of Lua programs. Larger step size values will make the garbage collector more aggressive, and also increase the step size of each incremental step of garbage collection. Values less than 100 may often lead to avoiding the garbage collector not completing its cycle and it is generally not preferred. The default value is 200, which means twice the speed of memory allocation for the garbage collector running.
Garbage collector functions
As developers, we do have Lua automatically managed memory. To do this, there are several methods.
- collectgarbage("collect"): A complete cycle of garbage collection.
- collectgarbage("count"): Returns the currently used kilobyte program memory amount
- collectgarbage("restart"): If the garbage collector has been stopped, it will restart.
- collectgarbage("setpause"): Set the value given as the second parameter divided by 100 to the garbage collector pause variable. Its purpose is as a discussion above.
- collectgarbage("setstepmul"): Sets the value of the variable given as the second parameter divided by 100 to the garbage step multiplier. Its purpose is as a discussion above.
- collectgarbage("step"): A step to run garbage collection. The second parameter is that the larger the step, the larger 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 is running.
Using a garbage collector, for example, a simple example is shown below.
print(collectgarbage("count"))
mytable = nil
print(collectgarbage("count"))
print(collectgarbage("collect"))
print(collectgarbage("count"))
When we run the above program, we will get the following output. Please note that this result will vary, as Lua automatic memory management capabilities may also differ in the operating system.
20.9853515625
0
19.4111328125
As can be seen from the above program, once the garbage collection is completed, the memory usage can be reduced. But it is not a mandatory call either. Even if we don't give calls, it will be automatically executed by the Lua interpreter after a predetermined time in the latter stage.
Obviously we can change these functional behaviors if needed using the garbage collector. These features provide a little extra capability to handle complex situations for developers. Depending on the memory required to execute the program type, this feature may or may not be used. But in the application's memory usage and in the program itself, to avoid not wanting to check the results after deployment.